Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Denkaufgabe: Bootprozess (Gelesen 313 mal)
|
|
Sebastian
YaBB God
 Offline
Einträge: 774
|
 |
Denkaufgabe: Bootprozess
« 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:
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
# /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:
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:
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:
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
|
| « Letzte Änderung: 10. August 2025, 11:04:21 von Sebastian » |
 Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Sebastian
YaBB God
Offline
Einträge: 774
|
|
Re:Denkaufgabe: Bootprozess
« Antwort #1 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
|
|
Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Sebastian
YaBB God
Offline
Einträge: 774
|
|
Re:Denkaufgabe: Bootprozess
« Antwort #2 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:
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
- 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
|
| « Letzte Änderung: 12. August 2025, 14:18:29 von Sebastian » |
Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
