Ein kleiner Bericht mit Installation entsprechend den Empfehlungen von systemd.Der Bootmanager systemd-boot wurde mit dem Ziel entwickelt den Bootvorgang schnell, einfach und sicher zu gestalten. Der Anwender erhält ein textbasiertes Bootmenü. Die Anzeige kommt ohne jeglichen Schnickschnack aus.
Er ist, dem Namen entsprechend, tief in systemd integriert und greift auf dort vorhandene Dienste zu. Jeder Menüeintrag beruht auf einer einzigen, eigenen Textdatei. Die Konfiguration für die Benutzerschnittstelle ist im Vergleich zu GRUB rudimentär und der Installationsumfang, mit 32 Dateien und einem zwanzigstel des Datenvolumens, sehr gering.
systemd-boot ist ausschließlich für UEFI Hardware verfügbar.
systemd-boot kann nur Betriebssysteme von Partitionen des gleichen Mediums booten. Um Betriebssysteme von weiteren Medien zu booten benutzt man die ChainLoader Technik zu GRUB oder einem anderen Bootloader.
AnwendungsszenarienEignung der Bootmanager bei unterschiedlichen Systemkonfigurationen.
| Konfiguration |sd-boot|GRUB| Bemerkung |
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Ein immutable OS │ ++ │ O │ Nur Bootmanager ohne Menü notwendig. │
│ │ │ │ GRUB ist für diesen Zweck überdimensioniert. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Ein OS auf einer HD │ ++ │ O │ Bootmenü nur bei mehreren Kerneln notwendig. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Mehrere Linux OS auf│ + │ + │ systemd-boot auf allen OS notwendig. │
│ einer HD │ │ │ GRUB benötigt externes Modul os-prober. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Dualboot mit WIN/MAC│ + │ + │ Wie zuvor. Bei beiden booten mittels ChainLoader │
│ auf einer HD │ │ │ möglich. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Mehrere Linux OS auf│ ━ │ + │ systemd-boot kann nur OS von einer HD booten. │
│ mehreren HD │ │ │ Zwei Instanzen im UEFI notwendig. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Dualboot mit WIN/MAC│ ━ │ + │ Wie zuvor. │
│ auf mehreren HD │ │ │ │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Mehrere Varianten │ │ │ Bei systemd-boot Anpassen der Menüeinträge nötig. │
│ eines Linux OS auf │ O │ O │ Bei GRUB die Datei "/etc/default/grub.d/xxxx.cfg" │
│ einer HD │ │ │ erstellen oder ändern. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Linux OS auf Btrfs │ │ │ systemd-boot erstellt Menüeinträge nur während der│
│ Dateisystem mit │ ━ │ O │ Installation der Kernel, egal aus welchem Sub- │
│ Unterstützung von │ │ │ volumen.Andere Subvolumen erhalten keinen Eintrag.│
│ snapper │ │ │ GRUB ist auf zu sätzliche Software angewiesen. │
├─────────────────────┼───────┼────┼───────────────────────────────────────────────────┤
│ Eine HD, │ │ │ systemd-boot reicht die Aufgaben an den Kernel und│
│ vollverschlüsselt │ ++ │ + │ User-Space weiter und ist dadurch effizienter. │
│ │ │ │ GRUB benötigt zusätzliche Software. │
└─────────────────────┴───────┴────┴───────────────────────────────────────────────────┘systemd-boot spielt seine Vorteile bei einem einfachen Hardware Setup voll aus, aber scheitert bei Betriebssystemen auf mehreren Medien. Für die Unterstützung von Btrfs Subvolumen zeichnet sich Dank openSUSE eine externe Lösung ab.
Grub wiederum ist universeller einsetzbar, dadurch schwergewichtig und benötigt trotzdem externe Software. Für einfache Hardware Setup ist Grub überdimensioniert.
systemd-boot installierenWer der Anleitung folgen möchte sollte
ungebingt seine Daten vorab auf einem externen Medium sichern. Es sind Arbeiten an Partitionen notwendig um systemd-boot den Empfehlungen entsprechend zu installieren.
Die Anleitung basiert auf der Standardinstallation von
siduction mit einer ESP (
Efi
System
Partition), die unter /boot/efi eingehangen ist. Dies ist auch der Standard für Debian und viele Debian Derivate.
Um zu systemd-boot zu wechseln sind nur die zwei Pakete
systemd-boot und
systemd-boot-efi notwendig.
Doch
Vorsicht, erst müssen wir unser System vorbereiten, um Verwirrung und unnötige Arbeit zu vermeiden.
PartitionierungEine wesentliche Änderung von systemd-boot gegenüber der Standardinstallation von siduction mit GRUB ist die Auslagerung des Verzeichnisses
/boot in eine oder besser zwei separate Partitionen. Die Empfehlungen von systemd-boot lauten:
-
Sowohl ESP als auch XBOOTLDR: ESP gdisk Partitionstyp "EF00", Part-GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93
Dateisystem: VFAT, eingehangen unter /efi/
Größe: 100 MB
XBOOTLDR gdisk Partitionstyp "EA00", Part-GUID code: BC13C2FF-59E6-4262-A352-B275FD6F7172
Dateisystem: Jedes, dass die UEFI-Implementierung lesen kann, eingehangen unter /boot/
Größe: mind. 1 GB
-
Nur ESP: (Bedingt empfohlen, siehe unten.)
gdisk Partitionstyp "EF00", Part-GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93
Dateisystem: VFAT, eingehangen unter /boot/
Größe: Mind. 1 GB
-
Nicht empfohlen: ESP eingehangen unter /boot/efi/
Wichtig Bitte die Erläuterungen hierzu weiter unten im gleichen Thema aufmerksam lesen:
https://forum.siduction.org/index.php?topic=9368.msg74530#msg74530Mindestgröße Hält man sich an die Empfehlungen von systemd-boot und benutzt sowohl die ESP als auch die XBOOTLDR Partition, kann man die geringe Größe der ESP beibehalten und für die XBOOTLDR Partition ein leistungsstärkeres Dateisystem verwenden. Notwendige Dateisystemtreiber für die XBOOTLDR Partition sind von
https://efi.akeo.ie zu holen und nach
/efi/EFI/systemd/drivers/ zu kopieren.
Die XBOOTLDR Partition sollte mindestens 1 GB umfassen, da systemd-boot alle Kernel und initrd darin doppelt ablegt. So wie es der Standard vorschreibt einmal direkt unter
/boot/ und ein weiteres Mal unter
/boot/<Kennung>/<Version>/. Damit fallen für einen Kernel mit initrd 70 bis 100 MB an. Der Grund hierfür dürfte in der möglichen Verwendung von VFAT, das keine Symlinks unterstützt, liegen. Bei mehreren OS mit jeweils mehreren Kernel ist die Größe von 1 GB grenzwertig und die bisher üblichen 200 bis 300 MB der ESP sind völlig untauglich. Das zieht eine Änderung der Partitonierung nach sich.
Partitionierung ändern Wir behalten die ESP in ihrer bisherigen Größe und erstellen an beliebiger Stelle auf dem gleichen Medium die XBOOTLDR Partition (gdisk Typ EA00). Wie bereits erwähnt mindestens 1 GB groß, besser 2 GB. Wenn sich dabei die UUID einer bereits vorhandenen Partition ändert, muss man die Datei
/etc/fstab anpassen.
Vorbereitung des SystemsWir öffnen ein Terminal und werden mit
su zu ROOT.
Sollte
gdisk nicht installiert sein, holen wir dies nach und lesen den
Partition GUID code der ESP und XBOOTLDR Partition aus. Die Gerätedatei kann natürlich auch
/dev/sda sein und die Ziffer hinter der Option
-i benennt die Partition auf dem Medium.
# sgdisk -i1 /dev/nvme0n1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
[...]
# sgdisk -i4 /dev/nvme0n1
Partition GUID code: BC13C2FF-59E6-4262-A352-B275FD6F7172 (XBOOTLDR partition)
[...]Die jeweils erste Zeile der Ausgabe von
sgdisk muss wie gezeigt aussehen. Wenn nicht, mit
gdisk den Partitionstyp zu
EF00 (ESP) und
EA00 (XBOOTLDR) ändern.
Im nächsten Schritt legen wir neue Verzeichnisse an und verschieben das Verzeichnis
/boot.
# cd /
# mkdir /efi
# mkdir /grub
# cp -a /boot/* /grub/
# umount /boot/efi/
# rm -r /boot/*Mit der Befehlsfolge sicherten wir auch die Daten der ESP.
Nun passen wir die Datei
/etc/fstab an. Ich erledige das vorzugsweise mit VIM.
# cp /etc/fstab /etc/fstab_$(date +%F)
# vim /etc/fstabVon der Zeile mit dem Einhängepunkt
/boot/efi entfernen wir den String "/boot".
Dann schreiben wir in eine neue Zeile die Daten für die XBOOTLDR Partition. Im Beispiel mit ext4 formatiert.
Schließlich sollten die Änderungen so aussehen.
UUID=FA62-156D /efi vfat defaults 0 2
UUID=<uuid_xbootldr> /boot ext4 defaults 0 2Jetzt hängen wir die Partitionen ein und kopieren den Kernel mit Zubehör nach
/boot. Dann erstellen wir noch das Verzeichnis für die Dateisystemtreiber der XBOOTLDR Partition.
# systemctl daemon-reload
# mount /boot/
# mount /efi/
# cp -a /grub/*-6.8.9-1-siduction-amd64 /boot/
# mkdir -p /efi/EFI/systemd/drivers/Zum Abschluss holen wir die Dateisystemtreiber von der Webseite
https://efi.akeo.ie und speichern sie im erstellten Verzeichnis
/efi/EFI/systemd/drivers/. Auf Ausführrechte achten.
InstallationSind die Vorbereitungen abgeschlossen und wurde das Ergebnis z.B. mit den Befehlen
ls -l /boot,
lsblk oder
sgdisk -i... überprüft, reicht eine Kommandozeile aus um die zwei benötigten Pakete unserem System hinzuzufügen und systemd-boot nach ESP und XBOOTLDR zu installieren.
# apt install systemd-boot-efi systemd-boot
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/BOOT/BOOTX64.EFI".
Created "/boot/e5cc6ff820c1450c93a29d8723c78cd1".
⚠️ Mount point '/efi' which backs the random seed file is world accessible, which is a security hole! ⚠️
⚠️ Random seed file '/efi/loader/random-seed' is world accessible, which is a security hole! ⚠️
Random seed file /efi/loader/random-seed successfully installed (32 bytes).
Created EFI boot entry "Linux Boot Manager".Im UEFI Menü finden wir jetzt an erster Stelle den
Linux Boot Manager, der in die ESP geschrieben wurde. Gleichzeitig hat systemd-boot die Booteinträge für den
Linux Boot Manager in der XBOOTLDR Partition erstellt.
Mit einem Reboot, gelangen wir jetzt ohne Umwege (Bootmenü) in das System, aus dem heraus die Installation ausgeführt wurde. Der
Linux Boot Manager kennt bisher nur dieses eine System mit einem Kernel und hat seine Konfiguration so eingestellt, dass das Menü übersprungen wird. Für jedes weitere OS auf dem Medium ist die
Vorbereitung des Systems und die
Installation notwendig.
KonfigurationEs gibt nur zwei Orte, an denen die Konfiguration für systemd-boot liegt.
Für den
Linux Boot Manager ist es die Datei
/efi/loader/loader.conf und für die
Menüeinträge sind es die Dateien mit der Erweiterung
.conf im Verzeichnis
/boot/loader/entries/.
Linux Boot ManagerBei nur einem System mit einem Kernel hat die Konfigurationsdatei folgenden Inhalt:
#timeout 3
#console-mode keepDas erklärt auch, warum wir bei unserem ersten Reboot direkt in das System gelangten, denn
timeout ist auskommentiert und somit das Menü deaktiviert. Wir entfernen das Kommentarzeichen. Ein erneuter Reboot zeigt uns nun das Menü einer frischen siduction XFCE Installation.
Debian GNU/Linux trixie/sid
Reboot Into Firmware InterfaceBei mehreren OS auf dem Medium erhält die Datei
/efi/loader/loader.conf eine zusätzliche Zeile
default <Kennnung>- um den Standardeintrag zu definieren. Wir dürfen diese Zeile ändern um ein anderes OS per default zu booten.
timeout 3
#console-mode keep
default e5cc6ff820c1450c93a29d8723c78cd1-*Menüeinträge Die Konfigurationsdateien liegen in dem Verzeichnis
/boot/loader/entries/ und ihr Name entspricht dem Format
<Kennung>-<Kernelversion>.conf.
systemd-boot fügt dem Menü bei der Installation weiterer Kernel automatisch die Einträge hinzu. Erhalten wir mit einem Dist-Upgrade einen zusätzlichen Kernel, sieht das Bootmenü so aus.
Debian GNU/Linux trixie/sid (6.8.10-1-siduction-amd64)
Debian GNU/Linux trixie/sid (6.8.9-1-siduction-amd64)Die Kernelversion hängt sd-boot, bei gleichem Text des Eintrags, automatisch an.
Von
mehreren OS auf unterschiedlichen Partitionen wird nur dasjenige automatisch im Menü aufgeführt, von dem aus systemd-boot installiert wurde. Die dort vorhandenen Kernel erscheinen in der Auswahl. Installiert man in jedem OS sd-boot, finden diese Booteinträge auch ihren Weg in das Menü. Hier zum Beispiel XUBUNTU.
Debian GNU/Linux trixie/sid
Ubuntu 24.04 LTSMenüeinträge ändern Grundsätzlich ändert systemd-boot einmal erstellte Menüeinträge nicht.
Man kann die Menüdatei im Verzeichnis
/boot/loader/entries/ nach Belieben anpassen.
Die maßgebliche Datei der siduction Installation ist
/boot/loader/entries/e5cc6ff820c1450c93a29d8723c78cd1-6.8.9-1-siduction-amd64.confWir ändern darin die Zeile
title zu
title siduction Giants XFCENun erscheint das Menü folgendermaßen:
siduction Giants XFCE (6.8.9-1-siduction-amd64)
Ubuntu 24.04 LTSSollte, aus welchen Gründen auch immer, ein Menüeintrag fehlen, kann die Generierung des Eintrags zu jeder Zeit erneut angestoßen werden. Es ist sicherzustellen, dass sich der Kernel, die initrd und die config- Datei der entsprechenden Version im Verzeichnis
/boot/ befinden.
Aus dem entsprechenden OS heraus erstellt der Befehl
dpkg-reconfigure linux-image-6.8.9-1-siduction-amd64auch den gewünschten Menüeintrag.
GRUB entfernenWir testen den neuen Bootloader ausführlich. Führen ein Dist-Upgrade mit einem neuen Kernel aus, entfernen einen alten Kernel, und prüfen ob systemd-boot die Menüeinträge erstellt und entfernt. Natürlich probieren wir auch alle Booteinträge aus.
Sofern die ausführlichen Tests von systemd-boot zu unserer Zufriedenheit ausfallen, können wir GRUB aus unserem System entfernen.
Pakete Wir öffnen ein Terminal, werden mit
su zu ROOT und benutzen den Befehl
apt purge, um auch die Konfigurationsdateien zu entfernen.
1|# apt purge grub*
2|[...]
3| /var/lib/dpkg/info/grub-btrfs.postrm: 23: update-grub: not found
4| dpkg: Fehler beim Bearbeiten des Paketes grub-btrfs (--purge):
5| Fehler traten auf beim Bearbeiten von:
6| grub-btrfsDas Paket
grub-btrfs wirft dabei einen Fehler aus. In Zeile 3 lesen wir, dass das post-removal-Skript den Befehl aus Zeile 23 (update-grub) nicht mehr findet, was natürlich richtig ist, denn
grub-pc-bin wurde bereits entfernt.
Folglich kommentieren wir die Zeile aus und bemühen apt noch einmal.
# sed -i '23s!\(.*\)!#\1!' /var/lib/dpkg/info/grub-btrfs.postrm
# apt purge grub-btrfsNach dieser Aktion sind eine Datei und ein Verzeichnis übrig, die siduction während der Erstinstallation anlegte, sowie die von uns erstellten Sicherungskopien.
Mit
# rm -r /etc/default/grub.d/
# rm -r /usr/share/grub/
# rm -r /grub/
# rm /etc/fstab_*entledigen wir uns der Überbleibsel.
UEFI bereinigen In der UEFI Firmware existiert noch der siduction Booteintrag aus der Erstinstallation mit GRUB. Wir lassen uns im Terminal mit ROOT-Rechten den Inhalt anzeigen. (Gekürzt dargestellt.)
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0002
Boot0000* siduction
Boot0001* Linux Boot Manager
Boot0002* EFI Hard DriveDer Befehl
# efibootmgr -b 0000 -Bentfernt den Eintrag von GRUB.
Anschließend löschen wir das zugehörige Verzeichnis aus
/efi/.
# rm -r /efi/EFI/siduction/StolpersteineParallele Installation zu GRUB ist möglich, aber nicht sinnvoll (siehe oben, Mountpoint und Größe der ESP). Auswahl des zu verwendenden Bootmanagers erfolgt über die UEFI Firmware oder ChainLoader Einträge im systemd Bootmenü. Man sollte auf jeden Fall auch eine XBOOTLDR Partition für systemd-boot verwenden, damit die Kernel nicht in der ESP abgelegt werden. In den Betriebssystemen, die GRUB verwenden, darf man dann die XBOOTLDR Partition nicht einhängen.
Es kursieren in Internet zu Hauf Anleitungen zur parallelen Installation. Sie sind meist kurz und erscheinen dadurch attraktiv. Ich kann davon nur dringend abraten. Viel zu schnell ist die ESP viel zu klein und eine nachträgliche Einrichtung der XBOOTLDR Partition ist umständlich, mühselig und fehlerbehaftet.
Besser ist es sich an Hand der Anwendungsszenarien für oder gegen systemd-boot zu entscheiden.
snapper Rollback auf Btrfs Dateisystemen werden nicht erkannt und gelistet. Nach einem Rollback bleibt der alte, bei der Erstinstallation von systemd-boot erstellte, Eintrag unverändert bestehen. Das Anpassen der Kernelzeile im Bootmenü mit dem gewünschten Subvolumen führte bei mir trotz vieler Versuche immer zu 'kernel panic'.
systemd-boot und Btrfs mit snapper Rollback harmonieren nicht miteinander, denn die Daten des /boot-Verzeichnisses sind ein wesentlicher Bestandteil des Betriebssystems und gehören in das Btrfs /-Subvolumen und nicht in eine separate Partition. Sonst sind Snapshots für Rollbackzwecke ungeeignet. Das Btrfs Dateisystem an sich ist dabei unerheblich.
Es bleibt abzuwarten welches Ergebnis openSUSE in nächster Zeit präsentiert.
Eigene Menüeinträge zu erstellen scheint einfach zu sein. Die Realität ist jedoch eine Andere. Das bloße Erstellen eines Verzeichnisses nach dem Muster
/boot/<Name>/<Kernelversion>/ und dorthin den Kernel und die initrd kopieren, zusätzlich die Datei
/boot/loader/entries/<Name>-<Kernelversion>.conf zu erzeugen, schlägt fehl. systemd-boot generiert während der Erstellung eines Menüeintrages eine initrd mit Optionen zu EFI. Nur mit dieser initrd gelingt der Bootvorgang.
Fazit- GRUB bleibt meiner Meinung nach die erste Wahl für einen Bootmanager. Er ist universeller einsetzbar und um ihn herum existiert eine ganze Reihe nützlicher Software.
- systemd-boot ist schneller, kleiner und hervorragend in systemd integriert, aber in einigen Szenarien unbrauchbar.
- Wer ein einfaches Hardware Setup sein Eigen nennt und um snapper einen Bogen macht, für den lohnt sich systemd-boot.
- Der Umstieg auf systemd-boot stellt für einen etwas geübten Nutzer keine große Herausforderung dar.
<Edit 19:10> Typo
<Edit 11.8. 19:02> sed-Befehl mit -i
