Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] Der Bootmanager systemd-boot  (Read 7875 times)

Offline scholle1

  • Global Moderator
  • User
  • *****
  • Posts: 130
[DE] Der Bootmanager systemd-boot
« on: 2024/06/04, 22:34:28 »
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.

Anwendungsszenarien

Eignung 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 installieren

Wer 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.

Partitionierung

Eine 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#msg74530

Mindestgröß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 Systems

Wir ö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.
Code: [Select]
# 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.
Code: [Select]
# 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.
Code: [Select]
# cp /etc/fstab /etc/fstab_$(date +%F)
# vim /etc/fstab
Von 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.
Code: [Select]
UUID=FA62-156D       /efi    vfat   defaults 0 2
UUID=<uuid_xbootldr> /boot   ext4   defaults 0 2
Jetzt 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.
Code: [Select]
# 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.

Installation

Sind 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.
Code: [Select]
# 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.

Konfiguration

Es 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 Manager
Bei nur einem System mit einem Kernel hat die Konfigurationsdatei folgenden Inhalt:
Code: [Select]
#timeout 3
#console-mode keep
Das 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.
Code: [Select]
      Debian GNU/Linux trixie/sid
     Reboot Into Firmware Interface
Bei 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.
Code: [Select]
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.
Code: [Select]
    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.
Code: [Select]
    Debian GNU/Linux trixie/sid
      Ubuntu 24.04 LTS

Menü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.conf

Wir ändern darin die Zeile title zu 
Code: [Select]
title      siduction Giants  XFCE
Nun erscheint das Menü folgendermaßen:
Code: [Select]
siduction Giants  XFCE (6.8.9-1-siduction-amd64)
                        Ubuntu 24.04 LTS
Sollte, 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
Code: [Select]
dpkg-reconfigure linux-image-6.8.9-1-siduction-amd64auch den gewünschten Menüeintrag.

GRUB entfernen

Wir 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.
Code: [Select]
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-btrfs
Das 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.

Code: [Select]
# sed -i '23s!\(.*\)!#\1!' /var/lib/dpkg/info/grub-btrfs.postrm
# apt purge grub-btrfs

Nach dieser Aktion sind eine Datei und ein Verzeichnis übrig, die siduction während der Erstinstallation anlegte, sowie die von uns erstellten Sicherungskopien.
Mit
Code: [Select]
# 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.)

Code: [Select]
# efibootmgr
 BootCurrent: 0001
 Timeout: 0 seconds
 BootOrder: 0001,0000,0002
 Boot0000* siduction
 Boot0001* Linux Boot Manager
 Boot0002* EFI Hard Drive
Der Befehl
Code: [Select]
# efibootmgr -b 0000 -Bentfernt den Eintrag von GRUB. 
Anschließend löschen wir das zugehörige Verzeichnis aus /efi/.
Code: [Select]
# rm -r /efi/EFI/siduction/
Stolpersteine

Parallele 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
« Last Edit: 2024/08/13, 13:28:12 by scholle1 »
"pax in terra" - Das ist mein großer, mein einzigster, von Herzen kommender Wunsch.
"Frieden auf der Erde" und alles Weitere erscheint einfach.

Offline unklarer

  • User
  • Posts: 886
Re: Der Bootmanager systemd-boot
« Reply #1 on: 2024/06/05, 08:53:55 »
+1    8)

Vielen Dank, für diese umfangreiche Arbeit und das Teilen im Forum, @scholle1!
Betrifft mich mangels Efi nicht, kann sich aber ändern, man weiß ja nie...    ;)

Offline scholle1

  • Global Moderator
  • User
  • *****
  • Posts: 130
Re: Der Bootmanager systemd-boot
« Reply #2 on: 2024/06/05, 11:46:10 »
Erläuterungen zur Partitionierung
und warum es eine gute Idee wäre die ESP in der bestehenden Größe zu behalten, sowie eine XBOOTLDR Partition mit mindestens 1 GB zusätzlich zu erstellen.

Übersetzte Zitate der boot_loader_specification https://uapi-group.org/specifications/specs/boot_loader_specification/

[Übersetzung Anfang] 
Hinweis: Diese Partitionen werden von allen Betriebssysteminstallationen auf derselben Festplatte gemeinsam genutzt, sodass alle denselben Ort für Einträge im Bootloader-Menü verwenden. 
[...] 
Das Einhängen des ESP in /boot/efi/, wie es traditionell gemacht wurde, wird nicht empfohlen. Eine solche verschachtelte Einrichtung erschwert eine Implementierung über direkte autofs-Einhängungen - wie sie beispielsweise von systemd implementiert werden -, da die Einrichtung des inneren autofs das äußere auslöst. Es wird empfohlen, die beiden Partitionen über autofs zu mounten. Da das einfache VFAT-Dateisystem eine geringe Datenintegrität aufweist, sollte es, wann immer möglich, nicht eingehängt werden. 
[...] 
Bei Systemen, bei denen die Firmware in der Lage ist, Dateisysteme direkt zu lesen, muss die ESP - und die GPT-XBOOTLDR-Partition sollte - ein Dateisystem sein, dass von der Firmware gelesen werden kann. Für die meisten Systeme bedeutet dies VFAT (16 oder 32 Bit). Anwendungen, die auf beide Partitionen zugreifen, sollten daher nicht davon ausgehen, dass ausgefeiltere Dateisystemfunktionen wie Symlinks, Hardlinks, Zugriffskontrolle oder Groß-/Kleinschreibung unterstützt werden. 
[Übersetzung Ende] 

Setup für systemd-boot
- ESP: Unveränderte Größe, eingehangen unter /efi
- XBOOTLDR Partition: Mindestens 1 GB, eingehangen unter /boot

Setup für GRUB
- ESP: Wie bisher einghangen unter /boot/efi
- XBOOTLDR Partition: Nicht verwenden

Zur Erinnerung: systemd-boot kann nur OS auf einem Medium verwalten. Booten von OS auf weiteren Medien nur mittels ChainLoder oder Auswahl über das UEFI möglich.
Will man für ein OS GRUB behalten, so liegt dessen Kernel innerhalb seines eigenen /boot Verzeichnisses. Somit findet der os-prober die Kernel der Installationen mit systemd-boot nicht. Die XBOOTLDR Partition ist hier nicht eingehangen. GRUB generiert ein sauberes Bootmenü und vermischt nicht die Kernel verschiedener Installationen.

systemd-boot nimmt für sich in Anspruch den Bootvorgang bestmöglich abzusichern. Da passt eine ESP, in der die Kernel liegen und die mit dem notwendigen VFAT Dateisystem formatiert ist, nicht hinein. Deshalb gehören die Kernel in die mit z.B. ext4 formatierte BOOTLDR Partition.
« Last Edit: 2024/06/05, 12:12:44 by scholle1 »
"pax in terra" - Das ist mein großer, mein einzigster, von Herzen kommender Wunsch.
"Frieden auf der Erde" und alles Weitere erscheint einfach.

Offline dibl

  • siduction community member
  • Global Moderator
  • User
  • *****
  • Posts: 2.403
    • Land of the Buckeye
Re: Der Bootmanager systemd-boot
« Reply #3 on: 2024/06/05, 14:14:20 »
Excellent report and analysis -- thank you.

I'll stay with grub.  ::)
System76 Oryx Pro, Intel Core i7-11800H, SSD 970 EVO Plus;  Asus ROG STRIX X299-E, Core i7-7740X, Nvidia GTX-1060, dual monitors, SSD 860 EVO

Offline OppaErich

  • OLE
  • User
  • Posts: 382
Re: Der Bootmanager systemd-boot
« Reply #4 on: 2024/06/05, 15:20:08 »
I'll stay with grub.  ::)
Petition to revive LILO!  8)

Offline edlin

  • User
  • Posts: 658
Re: Der Bootmanager systemd-boot
« Reply #5 on: 2024/06/05, 16:00:41 »
Danke, eine sehr schöne Übersicht inkl. der Grenzen und Möglichkeiten von systemd-boot. Könnte etwas für einen verregneten Sommertag sein. Auf meiner Spielwiese (Desktop) wird das aber nix: Mehrere Linux OS auf mehreren SSDs. Da bleibt GRUB. Aber meinen Tuxedo-Läppi muss ich eh mal aufräumen.

edlin
 
Der Kluge lernt aus allem und von jedem,
der Normale aus seinen Erfahrungen
und der Dumme weiß alles besser.

Sokrates

Offline ro_sid

  • User
  • Posts: 327
Re: Der Bootmanager systemd-boot
« Reply #6 on: 2024/06/05, 17:51:18 »
I'll stay with grub.  ::)
Petition to revive LILO!  8)
Hätte ich ja nichts dagegen :), aber LiLo kann kein "Multiboot" wie für z.B. Xen erforderlich.
Und wehe, man vergaß nach einer Kerneländerung den "Lilo-Lauf", dann bootete das System (ohne unveränderte Altversion) nicht mehr :o.
Das für mich tolle an Grub ist, sobald er "läuft" habe ich jede Chance, ein "verkorkstes" System wieder zum Booten zu bringen - und sei es über den 'c'li Kommando-Modus. Booten von einem anderen Medium eingeschlossen.

Offline scholle1

  • Global Moderator
  • User
  • *****
  • Posts: 130
Re: Der Bootmanager systemd-boot
« Reply #7 on: 2024/08/17, 15:46:06 »
Ein kleiner Bericht mit Installation entsprechend den Empfehlungen von systemd.
Weiterentwicklung

Wie im Bericht oben beschrieben, kämpft systemd-boot mit einigen Einschränkungen.
Besonders die unbefriedigende Situation mit dem Dateisystem Btrfs bei der
Verwendung von snapper mit Rollback, veranlassten mich tiefer in die Materie
einzutauchen und nach Lösungen zu suchen. Zusätzlich störte mich der Inhalt
der Booteinträge bei zwei Varianten der gleichen Distribution auf der Festplatte.

Systembeschreibung

UEFI, eine NVME mit GUID-Partitionstabelle (GPT)

Fünf Partitionen
  Partition 1: ESP 200MB VFAT Dateisystem
  Partition 2: siduction XFCE 80GB Btrfs Dateisystem
  Partition 3: siduction KDE 80GB Btrfs Dateisystem
  Partition 4: Ubuntu 85GB ext4 Dateisystem
  Partition 5: XBOOTLDR ext4 Dateisystem
Auf beiden siduction Installationen wurde systemd-boot installiert und GRUB
vollständig entfernt. Die ESP wird unter /efi eingehangen und die XBOOTLDR
unter /boot.
Ubuntu verwendet GRUB. Die XBOOTLDR wird nicht, und die ESP unter /boot/efi
eingehangen.

Inhalt der Booteinträge

Standard mit systemd-boot

Der Booteintrag für die erste siduction Installation sah so aus:
Code: [Select]
    Debian GNU/Linux trixie/sid
Das ist gut lesbar, aber entspricht nicht ganz den Tatsachen. Die Distribution
heißt siduction und basiert auf Debian sid.
Kommt durch ein Upgrade ein zweiter Kernel hinzu, enthalten die Booteinträge
die Kernelversion.
Code: [Select]
    Debian GNU/Linux trixie/sid (6.8.10-1-siduction-amd64)
    Debian GNU/Linux trixie/sid (6.8.9-1-siduction-amd64)

Auch diese Einträge sind leicht unterscheidbar und gut verständlich.
Anders verhält es sich, wenn die zweite siduction Variante hinzutritt und
beide nur einen Kernel beinhalten.
Code: [Select]
    Debian GNU/Linux trixie/sid ID e5cc6ff820c1450c93a29d8723c78cd1
    Debian GNU/Linux trixie/sid ID fb39997bb5fb4d1699693bc5499fda80

Wie soll der Benutzer hier erkennen, welcher Booteintrag zu welcher Variante
gehört?
Ganz verrückt wird die Angelegenheit, wenn die erste siduction Variante bereits
zwei Kernel enthält, und dann die zweite Variante mit nur einem Kernel hinzu
kommt. systemd erstellt für die zweite Variante Booteinträge für alle Kernel
die im Verzeichnis /boot liegen und der Kernelversion (-siduction-amd64)
entsprechen. Eine Prüfung, ob die entsprechenden Module unter /usr/lib/modules/
überhaupt existieren, erfolgt nicht.

Die besseren Booteinträge

systemd-boot liest für die Menüeinträge die Dateien /etc/os-release und
/usr/lib/os-release.
Erstere hat Vorrang vor der zweiten und ist während der Installation ein Link
auf /usr/lib/os-release.
Genau hier werden wir aktiv und ersetzen den Link, am besten bereits vor der
Installation von systemd-boot, durch eine Datei mit dem Inhalt

Code: [Select]
PRETTY_NAME="siduction Giants XFCE, snapshot @"
NAME="siduction"
VERSION_CODENAME=giants
VERSION="Giants"
VARIANT="XFCE"
VARIANT_ID=xfce
ID=siduction
ID_LIKE=debian
HOME_URL="https://siduction.org"
SUPPORT_URL="https://forum.siduction.org"

Im Ergebnis erhalten wir für zwei siduction Varianten, eine davon mit zwei Kerneln, das folgende Bootmenü:
Code: [Select]
    siduction Giants XFCE, snapshot @ (6.8.10-1-siduction-amd64)
    siduction Giants XFCE, snapshot @ (6.8.9-1-siduction-amd64)
                 siduction Giants KDE, snapshot @

Die Einträge sind jetzt klar und leicht verständlich. Das ist der Stand mit
dem Paket siduction-btrfs ab Version 0.2.0-5.

Menüeinträge nach Rollback auf Btrfs Dateisystem

Die grundsätzliche Schwierigkeit in der Kombination von systemd-boot mit dem
Btrfs Dateisystem besteht in dem Auslagern des Verzeichnisses /boot in
eine separate Partition. Dadurch geht die Zuordnung der Kernel zu den Snapshots
verloren.
Bei einem Rollback muss deshalb überprüft werden, welche Kernel zum Rollbackziel
gehören. Für diese Kernel erstellt man in einer chroot Umgebung die Menüeinträge.

Menüeinträge erstellen

Beispiel:
Nach einem Rollback wird Snapshot 9 zum Rollbackziel und neuem default
Subvolumen. Für Snapshot 9 existieren noch keine Menüeinträge, also bleiben wir
im alten Snapshot.
In einem Terminal werden wir mit su zu ROOT und hängen das Rollbackziel ein.
Code: [Select]
# mkdir /mnt/sn9
# mount -t btrfs -o subvol=@snapshots/9/snapshot/ /dev/nvme0n1p3 /mnt/sn9
# cd /mnt/sn9

Im Rollbackziel ändern wir in vier Dateien die Snapshot Nummer.
Die erste Zeile in /etc/os-release.
Code: [Select]
PRETTY_NAME="siduction Giants XFCE, snapshot 9"
Die Datei /etc/kernel/entry-token.
Code: [Select]
siduction-xfce-snapshot-9
Den String der Datei /etc/kernel/cmdline.
Code: [Select]
rootflags=subvol=@snapshots/9/snapshot
In der Datei /etc/fstab die Zeile für den Mount Point '/'.
Code: [Select]
UUID=<uuid_root_part> / btrfs subvol=@snapshots/9/snapshot,[...]
Nach diesen Vorbereitungen starten wir die chroot Umgebung.
Code: [Select]
/mnt/sn9# cd /
# for i in "/proc" "/run" "/sys" "/dev"; do mount --rbind ${i} /mnt/sn9${i} && mount --make-rslave /mnt/sn9${i}; done
# chroot /mnt/sn9 /usr/bin/bash

Als nächstes die beiden Partitionen ESP und XBOOTLDR einhängen.
Code: [Select]
# mount /efi
# mount /boot

Jetzt überprüfen wir, welche Kernelversionen in Snapshot 9 vorhanden sind.
Die entsprechenden Kernel und config Dateien benötigen wir auch im
Verzeichnis /boot
Code: [Select]
# ls /usr/lib/modules/
6.8.10-1-siduction-amd64 6.8.9-1-siduction-amd64

Der Befehl, für alle Kernelversionen ausgeführt,
Code: [Select]
dpkg-reconfigure linux-image-6.8.10-1-siduction-amd64erzeugt jeweils eine neue initrd und den gewünschten Booteintrag.

Aufräumen und die chroot Umgebung verlassen.

Code: [Select]
# umount /efi /boot
# exit
# for i in "/proc" "/run" "/sys" "/dev"; do umount -R /mnt/sn9${i}; done
# rmdir /mnt/sn9

Fazit und Ausblick

Obwohl systemd-boot auf Grund der Auslagerung des Verzeichnisses /boot in eine
eigene Partition nicht optimal mit dem Dateisystem Btrfs zusammenarbeitet,
lassen sich Menüeinträge nach einem Rollback erstellen.
Damit brauchen wir nicht abwarten, auf welche Weise SUSE das Problem löst.
Wir haben in siduction die oben geschilderten Änderungen und Erweiterungen in
unser Paket siduction-btrfs ab Version 0.2.0-5 aufgenommen. Gleichzeitig
wurde die Abhängigkeit zu GRUB gelöst. So kann der Benutzer selbst entscheiden
welchen Bootmanager er verwenden möchte und auf den jeweils anderen vollständig
verzichten.

Weitere Informationen
man machine-id
siduction-btrfs ab Version 0.2.0-5 auf https://github.com/siduction/siduction-btrfs
« Last Edit: 2024/08/17, 15:57:05 by scholle1 »
"pax in terra" - Das ist mein großer, mein einzigster, von Herzen kommender Wunsch.
"Frieden auf der Erde" und alles Weitere erscheint einfach.