Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe 
allgemeine Kategorie => Allgemeine Diskussionen => Thema von: Sebastian am 10. August 2025, 11:01:31
Titel: Denkaufgabe: Bootprozess
Beitrag von: Sebastian am 10. August 2025, 11:01:31
Hallo Suletuxe,

Gegeben sind einige Informationen zu einem fiktiven System. Eure Aufgabe ist es zu erklären, warum dieses System erfolgreich bootet, und auch die swap Partition gemountet wird, obwohl die folgenden Angaben fehlen:

  • Kein Eintrag für das Root-Dateisystem in der /etc/fstab
  • Kein Eintrag für die Swap-Partition in der /etc/fstab
  • Keine Datei /etc/crypttab vorhanden
  • Keine Parameter auf der Kernel-Cmdline zum Entschlüsseln oder Einhängen des Root-Dateisystems


    • Gegeben sind folgende Eckdaten zum System:

    • Init-System: systemd
    • Partitionstable: GPT
    • Bootloader: systemd-boot


      • gdisk Ausgabe:


      Code:

      GPT fdisk (gdisk) version 1.0.9

      Command (? for help): p
      Disk /dev/sda: 500118192 sectors, 238.5 GiB
      Sector size (logical): 512 bytes
      Disk identifier (GUID): 12345678-9ABC-DEF0-1234-56789ABCDEF0
      Partition table holds up to 128 entries

      Number Start (sector) End (sector) Size Code Name
      1 2048 4196351 2.0 GiB EF00 EFI
      2 4196352 479948799 226.0 GiB 8304 Linux x86-64 root (/)
      3 479948800 500117503 10.0 GiB 8200 Linux swap


      /etc/fstab

      Code:

      # /etc/fstab
      # <Dateisystem> <Einhängepunkt> <Typ> <Optionen> <Dump> <Pass>
      UUID=F104-1473 /efi vfat fmask=0173,dmask=0027 0 1
      UUID=3a2f6c3a-9b0f-4e76-ae1c-11a5d4d990fc /home btrfs subvol=@home,noatime,compress=zstd 0 0
      UUID=3a2f6c3a-9b0f-4e76-ae1c-11a5d4d990fc /var/cache btrfs subvol=@cache,noatime,compress=zstd 0 0


      lsblk -f Ausgabe:


      Code:

      NAME FSTYPE LABEL UUID MOUNTPOINT
      sda
      ├─sda1 vfat EFI F104-1473 /boot/efi
      ├─sda2 crypto_LUKS a1234567-89ab-cdef-0123-456789abcdef
      │ └─root btrfs 3a2f6c3a-9b0f-4e76-ae1c-11a5d4d990fc /
      │ └─root btrfs 3a2f6c3a-9b0f-4e76-ae1c-11a5d4d990fc /home
      │ └─root btrfs 3a2f6c3a-9b0f-4e76-ae1c-11a5d4d990fc /var/cache
      └─sda3 crypto_LUKS b2234567-89ab-cdef-0123-456789abcdef
      └─swap swap swap 8259f5a2-2c33-4cbe-b592-a5e3f8041d7d [SWAP]


      free -h Ausgabe:

      Code:

      total used free shared buff/cache available
      Mem: 7.8G 1.5G 4.0G 200M 2.3G 6.0G
      Swap: 10G 0G 10G


      Benutzte kernel Parameter zum booten:


      Code:

      initrd=\9bcb491b27344086841664ebccc2f3ce\6.15.9-arch1-1\initrd nvme_load=YES nowatchdog rw rootflags=subvol=/@,noatime,compress=zstd


      Viel Spass beim knobeln. Ich werde dann später auflösen, falls keiner drauf kommt.

      LG
      Sebastian
Titel: Re:Denkaufgabe: Bootprozess
Beitrag von: Sebastian am 11. August 2025, 12:39:56
Na, kommt niemand drauf?

Tipp: Systemd ist dafür verantwortlich, dass dieses System auch ohne einen Eintrag für die Root- und Swap-Partition in der Datei /etc/fstab unter bestimmten Voraussetzungen dennoch startet. Welche Voraussetzung ist das?

LG
Sebastian
Titel: Re:Denkaufgabe: Bootprozess
Beitrag von: Sebastian am 12. August 2025, 14:04:44
Ok, wenn keiner eine idee hat Löse ich jetzt mal auf:

Der Entscheidene Hinweis wäre aus der gdisk Ausgabe zu lesen gewesen:
Zitat:
GPT fdisk (gdisk) version 1.0.9

Command (? for help): p
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 12345678-9ABC-DEF0-1234-56789ABCDEF0
Partition table holds up to 128 entries

Number Start (sector) End (sector) Size Code Name
1 2048 4196351 2.0 GiB EF00 EFI
2 4196352 479948799 226.0 GiB 8304 Linux x86-64 root (/)
3 479948800 500117503 10.0 GiB 8200 Linux swap


Das System bleibt bootfähig, weil systemd beim Start automatisch die nötigen Units generiert. Konkret findet systemd-gpt-auto-generator die relevanten GPT‑Partitionen (Root, Swap) und erzeugt dafür Mount‑ und Swap‑Units. Parallel lesen systemd-fstab-generator und systemd-cryptsetup-generator die lokalen Konfigurationsdateien (/etc/fstab bzw. /etc/crypttab) ein und erzeugen daraus native Units. So greifen automatische Erkennung und explizite Konfiguration nahtlos ineinander.

systemd-gpt-auto-generator erkennt anhand der Partitionstyp-GUIDs einer GPT-Platte automatisch die Root‑Partition und weitere standardisierte Partitionen und generiert früh im Bootprozess die passenden Mount‑ und Swap‑Units. Ist auf der Kernel‑Cmdline root=gpt-auto gesetzt (oder root= weggelassen), wird die automatische Root-Erkennung aktiviert; eine explizite andere root=‑Angabe deaktiviert sie. Damit bleibt das System auch ohne explizite fstab‑Einträge bootfähig, solange die Discoverable‑Partitions‑Vorgaben eingehalten werden.

Funktionsweise von systemd-gpt-auto-generator

  • Erkennung per Typ‑GUID: Der Generator sucht Partitionen über ihre GPT‑Partitionstyp‑GUIDs (z. B. Root, Home, Var, Swap, ESP, XBOOTLDR) und erstellt daraus Mount‑/Swap‑Units. Das implementiert die Discoverable Partitions Specification (https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html)
  • Begrenzung auf GPT und Prioritäten: Auf Nicht‑GPT‑Systemen hat der Generator keine Wirkung. Er legt außerdem keine Mounts an, wenn Mountpunkte bereits Dateien enthalten oder wenn sie in fstab explizit konfiguriert sind; Einträge für ESP/XBOOTLDR werden übersprungen, wenn /boot bzw. /efi in fstab vorhanden ist4.
  • Bezug zur Boot‑Disk: Die Root‑Partition wird nur auf derselben physischen Disk gesucht wie die zum Booten genutzte ESP. Voraussetzung ist, dass der Bootloader die EFI‑Variable LoaderDevicePartUUID setzt; ohne diese kann die Root‑Partition nicht automatisch ermittelt werden


    • Rolle des systemd-fstab-generator

    systemd-fstab-generator übersetzt /etc/fstab beim frühen Systemstart in native systemd‑Units und instanziiert nötige Mount‑ und Swap‑Units. Über Kernel‑Parameter wie fstab=no kann die Auswertung unterdrückt werden. Zudem kann root=gpt-auto auf der Cmdline explizit die GPT‑Auto‑Erkennung der Root aktivieren. Existieren fstab‑Einträge, haben sie Vorrang vor automatisch generierten Mounts

    Rolle des systemd-cryptsetup-generator

    systemd-cryptsetup-generator übersetzt /etc/crypttab früh im Boot in systemd-cryptsetup@.service‑Instanzen, die verschlüsselte Blockgeräte entsperren. Die Services fragen Passwörter über die systemd‑Password‑Agent‑Logik ab und unterstützen auch Keyfiles/Token. Per Kernel‑Parametern (z. B. luks=, luks.uuid=) kann die Aktivierung gesteuert bzw. ergänzt werden.

    Da auch hier – analog zum systemd-fstab-generator – Einträge in der /etc/crypttab Vorrang vor der automatischen Konfiguration haben, führte in diesem Fall die Angabe der Typ-GUID der Root-Partition in der GPT (8304) dazu, dass die Automatik den LUKS-Container öffnen musste, um weiterhin nach dem Root-Dateisystem zu suchen.

    Fazit

    Die fehlenden Einträge in der /etc/fstab sowie die komplett fehlende /etc/crypttab in Kombination mit dem fehlenden Kernel-Parameter root= und der richtigen GUID Typen in der GPT waren entscheidend dafür, dass die systemd-Automatiken gegriffen haben.

    Da es sich hierbei um eine sehr untypische Systemkonfiguration handelt, dachte ich, sie eigne sich gut als kleines Rätsel – und ganz nebenbei bringt sie euch die Funktionalität von systemd näher. Schreibt gerne mal, ob ihr wusstet, dass systemd so etwas beherrscht!

    LG
    Sebastian


Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.