Leserartikel Arch Linux in Btrfs subvolume vollverschlüsselt installieren (zusammen mit anderen Distributionen)

[Fried.Ice]

Hallo zusammen.

Da im Thread zur neuen Version von openSuse die Frage aufkam, wie ich mein Installationssetup erstellt habe, möchte ich hier eine mehr oder weniger ausführliche Anleitung präsentieren. @Tacheles und @Beelzebot seien an dieser Stelle verlinkt.
Diese wäre im Ursprungsthread wohl doch ein wenig Offtopic gewesen, und vielleicht liest so der ein oder andere interessierte Leser mit und kann Verbesserungsvorschläge oder Anmerkungen anderer Natur hinterlassen.

Gleich vorweg: Dies ist keine Anleitung für Linux-Anfänger, sondern richtet sich an erfahrenere Nutzer.
Ich werde nicht auf die Installation oder Eigenheiten von Arch Linux an sich eingehen, sondern nur auf die Änderungen, die notwendig sind, um mein Setup zu betreiben.
Die Basisinformationen selbst sind im Arch Wiki bereits bestens zusammengefasst: https://wiki.archlinux.org/index.php/Installation_guide.


Worum genau geht es?

Ich habe in den letzen Monaten vermehrt meine Augen auf Btrfs gerichtet, da sich die Features wie z.B. das simple Anlegen von Snapshots oder auch die transparente Komprimierung sehr vielversprechend anhörten.
Im Zuge meines Hardwareupgrades wurde eine komplette 512 GB SSD frei, die ich nun rein für GNU/Linux verwende. Da ich von meinem Notebook eine Vollverschlüsselung gewohnt war, wollte ich diese nun auch auf dem Desktop nicht mehr missen. Zusätzlich wollte ich zum Experimentieren neben Arch auch noch weitere Distributionen verwenden, in meinem Fall waren das Gentoo und Ubuntu.

Ich hatte allerdings vorher schon oft kein gutes Händchen für die Abschätzung von Partitionsgrößen bewiesen, weshalb mit Btrfs in dieser Hinsicht sehr entgegen kam.
Mittels sogenannter subvolumes kann man, vereinfacht gesagt, mehrere "virtuelle" Partitionen innerhalb der Btrfs Partition anlegen, die sich den verfügbaren Platz dynamisch teilen, und separat gemounted werden können.

Der Plan sah also folgendermaßen aus:

• EFI Partition - fat32
• boot Partition - btrfs
  • Top level btrfs subvolumes für für jede /boot-Parition jeder Distribution - /ArchBoot, /GentooBoot, /UbuntuBoot
• LUKS/DmCrypt
  • LVM2
    • Root Partition - btrfs
      • Top level btrfs subvolumes für für jede / Parition jeder Distribution - /ArchRoot, /GentooRoot, /UbuntuRoot
      • Top level btrfs subvolumes für home, data und games, die je nach Bedarf in den jeweiligen Distris gemounted sind
    • Swap Partition

Anmerkungen:

• Dadurch, dass sich alle Distributionen ein Dateisystem teilen, besteht bei einem Dateisystemfehler das Risiko, dass alle Distributionen betroffen sind
• Andere Distributionen mit graphischen Installern kommen meiner Erfahrung nach nicht zurecht mit der Installation in selbstdefinierte Btrfs subvolumes, z.B. OpenSuse und Fedora konnte ich nicht erfolgreich zum Booten bringen (wer hier Vorschläge hat, gerade im Hinblick auf eine Installation aus einem chroot statt einem graphischen Installer, ist herzlich eingeladen, mich zu erleuchten! )
• Die Göße der Partitionen können nach belieben angepasst werden, ich habe meine Boot- und EFI-Partionen etwas großzügiger gewählt, um Reserven zu haben
• Im Ursprungsthread wurde vorgeschlagen, auf LVM2 zu verzichten, in dem man die Swap-Partition "mit einem random key verschluesselt von dem jeweiligen gebooteten system mountet". Der Grund, dass ich das nicht so ausgelegt habe, liegt darin, dass ich den Swap für Hibernation nutzen wollte, und dies meines Wissens nach anders nicht möglich war. Falls das nicht der Fall sein sollte, möge man mich eines Besseren belehren.

An dieser Stelle möchte ich auf wichtige Wiki-Seiten verweisen, die die Details aufbereiten:

• https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS
• https://wiki.archlinux.org/index.php/Btrfs
• https://wiki.archlinux.org/index.php/Installation_guide (auch an dieser Stelle sei dies nochmal erwähnt )

Disclaimer:
Die Änderungen, die nach den angegebenen Schritten durchgeführt werden, können zu Datenverlust führen.
Klemmt also sicherheitshalber andere Festplatten ab und/oder habt Backups von wichtigen Daten auf anderen, physisch nicht angeschlossenen Festplatten, vorrätig.
Alle Handlungen erfolgen auf eigene Gefahr.


Nun folgt, ohne große Umschweife, die eigentliche Anleitung:

/dev/sda ist ein Platzhalter, welcher durch das gewünschte Blockdevice ersetzt werden muss.

1. Boot vom Installationsmedium (USB-Stick/CD)
2. Partitionierung der Festplatte (ich nehme gerne fdisk dazu)
   1. Partition layout: GPT
   2. Partition 1: EFI Systempartition /dev/sda1 (bei mir: 512 MB)
   3. Partition 2: Linux File System /dev/sda2 (bei mir: 3,5 GB)
   4. Partition 3: Linux File System /dev/sda3 (bei mir: Rest)
3. Anlegen des Dm-Crypt Containers für die Haupt-Partition (hier bei bedarf eigene Verschlüsselungs-Parameter angeben, siehe https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode)
   1. cryptsetup luksFormat /dev/sda3
4. Öffnen des Dm-Crypt Containers auf den mapper crypt (Name kann beliebig geändert werden)
   1. cryptsetup open /dev/sda3 crypt
5. Anlegen des LVM
   1. pvcreate /dev/mapper/crypt
   2. vgcreate mainLvmGroup /dev/mapper/crypt (Name kann beliebig geändert werden)
   3. lvcreate -L 440G mainLvmGroup -n BetterRoot (Name und Größe kann beliebig geändert werden)
   4. lvcreate -l 100%FREE mainLvmGroup -n swap (Name kann beliebig geändert werden)
6. Anlegen der Dateisysteme (Bei Bedarf Paramter für Spezialisierung angeben)
   1. mkfs.vfat -F 32 /dev/sda1
   2. mkfs.btrfs /dev/sda2
   3. mkfs.btrfs /dev/mapper/mainLvmGroup-BetterRoot
   4. mkswap /dev/mapper/mainLvmGroup-swap
7. Anlegen der Btrfs subvolumes (Ich verwende hier bewusst nicht die geläufige Form der Benennung von root level Subvolumes mittels @ - mich persönlich verwirrt das mehr, als es hilft. Das kann natürlich jeder so handhaben, wie es ihm beliebt.)
   1. HauptPartition
      1. mount /dev/mapper/mainLvmGroup-BetterRoot /mnt
      2. btrfs subvolume create /mnt/ArchRoot
      3. btrfs subvolume create /mnt/UbuntuRoot
      4. ...
      5. Hier ist auch der passende Augenblick, falls für spezielle Unterverzeichnisse subvolumes gewünscht werden
         1. btrfs subvolume create /mnt/ArchRoot/home
         2. ...
      6. umount /mnt
   2. BootPartition
      1. mount /dev/sda2 /mnt
      2. btrfs subvolume create /mnt/ArchBoot
      3. btrfs subvolume create /mnt/UbuntuBoot
      4. ...
      5. umount /mnt
8. Mounten der Partitionen
   1. mount /dev/mapper/mainLvmGroup-BetterRoot /mnt -o subvol=/ArchRoot
   2. mkdir /mnt/boot
   3. mount /dev/sda2 /mnt/boot -o subvol=/ArchBoot
   4. mkdir /mnt/boot/efi
   5. mount /dev/sda1 /mnt/boot/efi
   6. swapon /dev/mapper/mainLvmGroup-swap
9. Installation des Base Systems (weitere Pakete für z.B. für die Netzwerkkonfiguration sind hinzufügen, z.B. dhcpcd oder wpa_supplicant oder etwa linux-firmware)
   1. pacstrap /mnt base linux grub efibootmgr btrfs-progs lvm2
10. fstab Erzeugung
    1. genfstab -U /mnt > /mnt/etc/fstab
11. Konfiguration des Systems (siehe https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration)
    1. arch-chroot /mnt
    2. Füge benötigte Hooks zum initramfs hinzu
       1. /etc/mkinitcpio.conf: HOOKS=(base udev autodetect keyboard keymap consolefont modconf btrfs block encrypt lvm2 resume filesystems keyboard fsck)
    3. Erstelle initramfs neu, um die Änderungen zu übernehmen
       1. mkinitcpio -P
    4. Setze Flags für den Kernel
       1. /etc/default/grub: GRUB_CMDLINE_LINUX="cryptdevice=UUID=${UUID_of_/dev/sda3}:crypt root=/dev/mainLvmGroup/BetterRoot rootflags=subvol=/ArchRoot resume=/dev/mainLvmGroup/swap"
    5. Installiere grub für EFI
       1. grub-install --efi-directory=/boot/efi --bootloader-id=arch
    6. Erzeuge neue grub Konfiguration
       1. grub-mkconfig -o /boot/grub/grub.cfg
    7. Andere Konfigurationsschritte
       1. timezone
       2. keymap
       3. ...

Damit ist die Basisinstallation abgeschlossen.
Das System kann nun gebootet werden.
Sollte es später mal notwendig sein, das System manuell mounten zu müssen (weil z.B. der Bootloader nicht korrekt konfiguriert wurde, die Pakete zur Netzwerkeinrichtung vergessen wurden etc.), können folgende Schritte ausgehend vom Bootmedium eingeleitet werden:

1. cryptsetup open /dev/sda3 crypt
2. mount /dev/mapper/mainLvmGroup-BetterRoot /mnt -o subvol=/ArchRoot
3. arch-chroot /mnt
4. mount -a # Mountet die in der /etc/fstab definierten Partitionen wie z.B. /boot; wichtig, falls auf diese z.B. bei einem Kernelupdate geschrieben werden soll
5. ...

Nun zur Installation von Ubuntu und Gentoo.
Es bietet sich an, die Installation gleich aus dem bereits installierten Archlinux vorzunehmen, da so (im Falle von Gentoo) bereits eine graphische Desktopumgebung installiert ist und man parallel zur Installation am gleichen Rechner Recherche und copy und paste betreiben kann.

• Ubuntu
  1. Mounte alle notwendigen Partitionen (/, /boot und /boot/efi) analog zur bisherigen Anleitung (/ ist bei mir im Folgenden im Hostsystem unter /mnt/UbuntuRoot gemounted)
  2. Installation Basissystem
     1. debootstrap --variant=minbase --arch=amd64 focal /mnt/UbuntuRoot http://de.archive.ubuntu.com/ubuntu
  3. /etc/fstab erzeugen
     1. genfstab -U /mnt/UbuntuRoot/ > /mnt/UbuntuRoot/etc/fstab (genfstab ist im Paket arch-install-scripts enthalten)
  4. Systemkonfiguration
     1. arch-chroot /mnt/UbuntuRoot (arch-chroot ist im Paket arch-install-scripts enthalten)
     2. mount -a
     3. /etc/crypttab konfigurieren
        1. Diese Datei ersetzt die Kernelparamter bei Arch
        2. crypt UUID="${UUID_of_/dev/sda3}" none luks
     4. Kernel installieren
        1. apt install linux-generic -> grub-pc wird automatisch mit eingerichtet (warum halt auch nicht ...), Enter drücken um zu bestätigen, dass keine grub Installation getätigt werden soll
     5. Installiere weitere Pakete
        1. apt install grub-efi cryptsetup lvm2 btrfs-progs language-pack-en
        2. apt remove grub-pc
     6. Boot konfigurieren (https://wiki.ubuntuusers.de/System_verschlüsseln/)
        1. dm-crypt zu /etc/modules hinzufügen
        2. export PATH="$PATH:/sbin"
        3. update-grub
        4. grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu
        5. update-initramfs
• Gentoo werde ich hier nicht näher betrachten, das Gentoo Wiki leistet gute Hilfestellung und die Installation verläuft analog zu den bereits aufgezeigten Installationen.

Ich habe versucht, meine Installation in einer VM nachzubilden, bekomme aber aktuell Ubuntu nicht zum booten, da scheint gerade etwas im Argen mit den lvm2 initramfs Scripten zu sein, siehe auch https://bugs.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/+bug/1873797.
Meine ursprüngliche Installation habe ich unter 19.10 getätigt, da hat alles wunderbar funktioniert.


Ich hoffe, dieser Beitrag war für den ein oder anderen hilfreich oder inspirierend, bitte zögert nicht mit Anmerkungen und Fragen!

 

[konkretor]

@SV3N das wäre doch was für die Startseite

Sehr toller Beitrag

 

[SVΞN]

Aber gerne doch, toller Artikel.

Ticket für die Startseite morgen ist gebucht.

Danke @konkretor für den Hinweis.

Liebe Grüße,
Sven

 

[Fried.Ice]

Damit habe ich gar nicht gerechnet, vielen Dank.

 

[Sulik]

Wusste gar nicht, dass luksOpen nicht mehr gebraucht wird... Muss ich mal meine Skripte anpassen 😅

 

[das_nervt]

👍
Habe das nicht nachgestellt, aber mir kommt unter
8. Mount die 4. mkdir /boot/efi komisch vor. Sollte das /boot/efi nicht /mnt/boot/efi sein?

 

[snaxilian]

Kann man sich mit der Nutzung von Btrfs nicht den ganzen LVM2 Kram sparen? Btrfs hat ja by design einen Volume Manager integriert über die Subvolumes oder übersehe ich hier irgendeine wichtige Funktion/Feature die LVM2 zwingend notwendig macht?

 

[2Stoned]

Danke für den ausführlichen Beitrag.

/home, /data und /games mountest du ja einfach rein: installierst du Programme, sagen wir mal Thunderbird, auch nur einmalig und Arch und Ubuntu nutzen dann sozusagen die gleiche Installation von Thunderbird ohne jegliche Probleme?
Ich frage, da bei mir z. B. Manjaro manchmal etwas Anpassung erfordert, um Programme sauber zu installieren/auszuführen, wo unter Arch einfach alles out-of-the-box läuft.

 

[snaxilian]

@2Stoned Die Installation musst schon pro Distribution durchführen, da unterschiedliche Paketformate, Versionen etc. Aber man könnte sich die Configdateien unter /etc als auch die Nutzdaten unter /home theoretisch teilen. Natürlich nur solange alle installierten Versionen keine Unterschiede in den Configs etc mit sich bringen.

 

[cgs]

Finde die Idee interessant.

• Würde ein /home das sie die Distributionen sich teilen nicht Sinn manchen
• Warum kein Opal? Das spart den ganzen Zirkus mit Luks und LVM

 

[CorePoint]

Cooler Post, hat bestimmt viel mühe gemacht.
Zu dem LVM verzicht ding, warum nicht 'n swapfile? Nutze das so mit luks-on-lvm auch für hibernation (ohne btrfs) und wüsste nicht was dagegen sprechen sollte, das einzige was beachtet werden muss sollte hier stehen, oder habe ich irgendwas übersehen? Wäre ja cool die komplexität 'n bisschen senken zu können.

 

[Fried.Ice]

Danke für eure zahlreichen Kommentare!

Sollte das /boot/efi nicht /mnt/boot/efi sein?

Vollkommen richtig, habe ich soeben korrigiert, vielen Dank!

Kann man sich mit der Nutzung von Btrfs nicht den ganzen LVM2 Kram sparen? Btrfs hat ja by design einen Volume Manager integriert über die Subvolumes oder übersehe ich hier irgendeine wichtige Funktion/Feature die LVM2 zwingend notwendig macht?

warum nicht 'n swapfile

Innerhalb der Subvolumes hat man immer noch ein Btrfs Dateisystem gegeben, dass kann man leider nicht mal so eben als Swap formatieren.

LVM benötige ich deshalb zur Zeit ausschließlich für die gemeinsame Verschlüsselung von Root-Partition und Swap.
Seit Kernel 5.0.0 ist wohl auch wie bereits von @CorePoint erwähnt eine Swapfile innerhalb der Btrfs-Partition möglich: [1], [2].
Die einzige Einschränkung die sich damit zu ergeben scheint ist, dass eine solche Swapfile wohl nicht möglich ist, wenn die Partition mehr als "one device" überspannt. Ich schätze mal, dass damit die "Raid" Features von Btrfs gemeint sind.
Da das bei mir allerdings nicht zutrifft, könnte man sich den ganzen Aufwand mit dem zusätzlichen LVM-Container tatsächlich sparen. Ich werde das demnächst mal ausprobieren und berichten.
Danke für die Anmerkungen!

installierst du Programme, sagen wir mal Thunderbird, auch nur einmalig und Arch und Ubuntu nutzen dann sozusagen die gleiche Installation von Thunderbird ohne jegliche Probleme?

man könnte sich die Configdateien unter /etc als auch die Nutzdaten unter /home theoretisch teilen

Native Pakete teile ich nicht zwischen den Distributionen, das würde mit verschiedenen Paketmanagern, Paketversionen und unterschiedlichen Dateisystemstrukturen auch gar nicht funktionieren.
Ich könnte mir allerdings vorstellen, dass plattftormübergreifende Paketierungssysteme wie Flatpack oder Snap auf diese Weise geteilt werden könnten. Das müsste man sich bei Interesse aber mal genauer anschauen.

Wenn man es genau nimmt mache ich etwas derartiges ja bereits:
Meine Steambibliothek liegt auf dem Root Level Subvolume /games, dass ich bei Ubuntu und Gentoo unter ~/games gemounted habe.

In /etc habe ich keinerlei Dateien geteilt, das ist in den meisten Fällen zu distributionsspezifisch bei mir.
Das einzige was mir auf die Schnelle einfällt, wo es bei mir Sinn ergeben würde, wäre die /etc/pulse/daemon.conf .

Würde ein /home das sie die Distributionen sich teilen nicht Sinn manchen

Ich habe für meine Haupt-Distribution (Arch) tatsächlich /home als Root Level Subvolume angelegt. Das hat wie sonst halt auch den Vorteil, dass ich bei einer Neuinstallation (kann ja aus den verschiedensten Gründen notwendig sein) mein Subvolume für /, also global im Btfrs gesehen /ArchRoot einfach löschen und neu anlegen kann ohne meine Nutzerdaten sichern zu müssen.
Alle Dateien in /home möchte ich dann aber dann auch nicht teilen, da ich z.B in Ubuntu viel herumexperimentiere und den entstandenen Datenmüll an Konfigurationsdateien nicht auf meinem Hauptsystem liegen haben möchte.
Meiner Erfahrung nach kommt z.B auch Firefox nicht so gut damit klar, wenn man einen Profilordner, welcher mit einer neueren Version erstellt wurde, nuzt. Bei Gentoo ist beispielsweise der stable Firefox ebuild immer auf dem LTS Release.

Aus diesem Grund habe ich mir auf meinem Root Level Subvolume /data einen Ordner für wichtige Dotfiles (z.B. für git, sway, mpd) angelegt und lege für diese dann manuell Symlinks aus den /home Verzeichnissen aller Distributionen an.
Ja, das ist ein wenig umständlich, andererseits kann ich diesen Ordner dann auch zentral per git versionieren (habe ich mir immer wieder vorgenommen, aber nie gemacht )

Auf /data liegen dann auch die ganzen manuell angelegten Daten wie Dokumente, Sourcecode und VM Images.
Mediendateien liegen derzeit noch auf einer NTFS Partition, da diese auch von Windows aus genutzt werden.

Warum kein Opal? Das spart den ganzen Zirkus mit Luks und LVM

Ich muss gestehen, dass ich mir Opal in der Vergangenheit nicht wirklich detailliert angeschaut habe.
Auf den ersten Blick scheine ich dort aber auf die Implementierung meines Hardwareherstellers angewiesen zu sein. Ich muss also in meinem Fall Crucial/Micron vertrauen und hoffen, dass die Implementierung korrekt ist und keine Backdoors enthält. Da greife ich persönlich dann lieber auf freie, öffentlich verfügbare Software zurück. Wobei der Performace-Impact sich mit AES Hardwarebeschleunigung ja auch wirklich in Grenzen hält.
Bitte korrigiere mich, wenn meine Annahmen falsch sind.

 

[Tacheles]

Wenn ich nach 5-6 Jahren mal Arch auf eine neue Platte installiere und dabei meine Doku's mit dem Archwiki abgleiche, ueberlege ich mit zunehmenden Alter manchmal schon warum ich mir den Aufwand antuh und nicht einfach in 10 min zB. Fedora installiere, aber einmal von der Freiheit gekostet mag man sie auch nicht mehr hergeben.

Was die swap & hibernation angeht glaube ich das deine LVM die einfachere Variante ist. Mit random key encrytion kannst du kein hibernation nutzen und die physical address einer swapfile in jedem installierten System zu konfigurieren ist imo zu viel Aufwand.

Danke fuer deinen sehr informativen Post, ist schoen wenn ich mal was wissenswertes hinzulerne.

 

[Snakeeater]

Wirklich interessanter Beitrag, ich verstehe zwar nur einen verschwinden geringen Teil aber dennoch schön zu sehen das hier im Forum ein paar versierte Linuxnutzer ansäßig sind.

Eigentlich habe ich nach einem "simplen" Btrfs setup für einen personal computer gesucht, da ich ebenfalls auf den Geschmack gekommen bin mich mit diesem Filesystem etwas genauer zu beschäftigen und ich die Flexibilität und Zukunftssicherheit gerne ausprobieren würde.

Gibt es daher so eine Anleitung auch für eine "normale" Linuxinstallation mit Btrfs? Mich interessieren hier besonders mögliche Raidfunktionalitäten mit der man die inhärente Heilungsfunktion des FS nutzen kann. Auch ein zukunftsorienterte Paritionierung würde mich im Detail interessieren (/home auf einer anderen "Platte" auslagern). etc.

 

[snaxilian]

@Snakeeater Schau dir opensuse an, das nutzt afaik btrfs standardmäßig. Ansonsten die Raidfunktionalität von btrfs ist beschränkt auf stripe und mirror, also 0 und 1. Theoretisch geht zwar auch parity (raid 5) aber das ist nach wie vor ziemlich instabil.
Was auch immer du unter einer zukunftsträchtigen Partitionierung verstehst aber es gibt je nach Nutzungsfall (leicht) unterschiedliche sinnvolle Aufteilungen. Ein separates /boot macht z.B. Sinn wenn man mehrere Betriebssysteme parallel nutzen will u.v.a. bei einer vollständigen Verschlüsselung des Systems, gleiches gilt für /home, zusätzlich sollte/kann man aus Sicherheitserwägungen /tmp in eine eigene Partition/Subvolume stecken und aus Stabilitätsgründen bei Servern /var/log.

@Fried.Ice Siehe zum Thema Encryption und BTRFS auch diesen Artikel im Archwiki mit entsprechenden Vergleichen: https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
Achtung: Der Artikel ist teilweise veraltet, z.B. wird davor gewarnt, dass GRUB nur mit luks1 kompatibel sei, dies ist seit Anfang diesen Jahres nicht mehr der Fall und es kann auch luks2 verwendet werden (Quelle).

 

[Snakeeater]

Vielen Dank für die Hinweise, werde mich da mal genauer einlesen. Lustigerweise nutze ich seit Jahren OpenSuse Tumbleweed privat und Snapper ist einer der Gründe das ich auf btrfs aufmerksam geworden bin. Nun möchte ich die Materie dahinter genauer verstehen und an meine Bedürfnisse anpassen.

 

[Fried.Ice]

@snaxilian
cryptsetup luksFormat legt mit neueren Versionen automatisch LUKS Header nach Version 2 an: [1]+[2].
Auch bei mir wird deshalb bereits mit den erwähnten Befehlen diese Version verwendet:

$ cryptsetup luksDump /dev/sdb3
LUKS header information
Version:           2
Epoch:             3
[...]

Die Limitierung gegenüber LUKS2 bezieht sich meines Verständnisses auch nur auf die /boot Partition selber.
Die eigentliche Entschlüsselung der Root-Partition geschieht dann durch das initramfs, das wie der Kernel selbst unverschlüsselt auf der /boot Partition liegt. Das einzige, was Grub bei meinem Setup selbst unterstützen muss, ist das Mounten des korrekten Btrfs Subvolumes auf der Boot Partition, im Falle von Arch also /ArchBoot.
Siehe auch https://wiki.archlinux.org/index.php/Arch_boot_process#Boot_loader.

So wie ich das sehe, ist der von dir verlinkte Commit auch noch nicht in einem stable Release von Grub angekommen, demnach stimmt also die Dokumentation des Archwiki für die aktuell enthaltene Grub Version. Siehe auch https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/grub.