platform-docs/adr/0016-grub-standardeintrag-luecken-geschlossen.md
Thomas Stallinger 4b188b8f3a docs: Gegenlese aller 16 ADRs - Dateinamen in ADR-0016 präzisiert, Querverweis ergänzt
ADR-0016 übernahm ADR-0009s verkürzte Dateinamen (boot-grub.cfg/
isolinux-live.cfg) ungeprüft - die tatsächlichen Dateien heißen laut
Git-Historie seit ihrer Anlage mit mint-Präfix (mint-boot-grub.cfg/
mint-isolinux-live.cfg). Jetzt korrekt benannt, mit Hinweis auf die
Diskrepanz zu ADR-0009s Kurzform.

13-live-provisioning-boot.md: Vorwärtsverweis auf ADR-0016 an der
Stelle ergänzt, die die ursprüngliche 01.08.2026-Korrektur beschreibt -
für Leser, die von dort aus nachvollziehen wollen, dass die Korrektur
zunächst nicht überall ankam.

Restliche 15 ADRs erneut gegen die letzte Fassung geprüft: alle
vorherigen Korrekturen (0003, 0009, 0011, 0012, 0013, 0015) live und
korrekt formatiert bestätigt, keine neuen Befunde.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 22:05:18 +02:00

35 lines
4.6 KiB
Markdown

# ADR-0016: GRUB-Standardeintrag — verbliebene Lücken zur bereits getroffenen Sicherheitsentscheidung geschlossen
**Status:** Beschlossen
**Datum:** 12.08.2026
## Kontext
ADR-0009 stellte am 01.08.2026 fest, dass der GRUB-Standardeintrag (bei Ablauf des Countdowns ohne Nutzereingriff) fälschlich auf den unbeaufsichtigten Auto-Install-Ablauf zeigte, statt auf ein sicheres „von lokaler Festplatte booten" — korrigiert in den Test-Bootmenüs zum damaligen Zeitpunkt (`grub/mint-boot-grub.cfg` für UEFI, `grub/mint-isolinux-live.cfg` für BIOS — ADR-0009 selbst nennt sie verkürzt `boot-grub.cfg`/`isolinux-live.cfg`, tatsächlich hießen die Dateien laut Git-Historie von Anfang an mit `mint-`-Präfix), und in `architecture/13-live-provisioning-boot.md` als geltende Architektur festgehalten.
Eine spätere, gezielte Gegenlese aller ADRs live gegen den tatsächlichen Stand auf anode (siehe Chatverlauf, 12.08.2026) deckte auf, dass diese Korrektur nicht überall tatsächlich ankam:
1. `13-live-provisioning-boot.md` widersprach sich selbst — ein älterer, nie nachgezogener Abschnitt behauptete weiterhin unkorrigiert das Gegenteil (behoben, siehe Commit vom 12.08.2026, kein eigenes ADR).
2. Beim Nachschauen der tatsächlichen Boot-Configs in `tuxflotte-installer` zeigte sich: `grub/mint-boot-grub.cfg` hat einen zweiten, für Nicht-EFI-Systeme gedachten Zweig (`grub_platform != efi`) ganz ohne „lokale Festplatte"-Eintrag — `set default="0"` fällt dort auf den ersten, harmlosen Menüeintrag zurück (normaler Live-Boot, nicht der Auto-Install-Eintrag), mit hoher Wahrscheinlichkeit ohnehin unerreichbar, weil `scripts/build.sh` für BIOS-Boot tatsächlich `isolinux` einsetzt, nicht diesen GRUB-Zweig.
3. Die parallelen Fedora-Bootmenüs (`grub/EFI-BOOT-grub.cfg`, `grub/boot-grub2-grub.cfg`) wurden bei der ursprünglichen Korrektur am 01.08.2026 gar nicht angefasst — beide hatten weiterhin unverändert `set default="0"`, und Index 0 ist dort **„Tuxflotte Provisioning (automatisch)"**, der unbeaufsichtigte Install-Eintrag. Anders als Punkt 2 ist das kein wahrscheinlich unerreichbarer Zweig, sondern die tatsächlich verwendete Konfiguration, sollte das Fedora-Backend (laut ADR-0009 bewusst nicht rückgebaut, für eine mögliche künftige Wiederaufnahme) je wieder aktiviert werden.
## Entscheidung
Alle vier Boot-Konfigurationsdateien in `tuxflotte-installer/grub/` folgen jetzt einheitlich demselben, bereits in ADR-0009 getroffenen Prinzip: der Standardeintrag bei Countdown-Ablauf ist immer „von lokaler Festplatte/Firmware booten", nie ein Installations- oder Auto-Install-Pfad.
- `mint-boot-grub.cfg`: der nicht-EFI-Zweig bekommt denselben „Von lokaler Festplatte booten (Standard)"-Menüeintrag samt `set default` wie der EFI-Zweig, statt sich auf dessen vermutete Nichterreichbarkeit zu verlassen — bewusste Verteidigung in der Tiefe, kein Vertrauen auf eine Annahme über die Boot-Katalog-Struktur.
- `EFI-BOOT-grub.cfg` (Fedora, EFI): `set default="0"``set default="Lokales UEFI-System booten"`.
- `boot-grub2-grub.cfg` (Fedora, BIOS): `set default="0"``set default="Von erster lokaler Festplatte booten"`.
Kein Rückbau/keine Entfernung von Einträgen — die Auto-Install-Menüpunkte bleiben bestehen und auswählbar, nur nicht mehr die Standardauswahl bei Nichtstun.
Alle vier Dateien mit `grub2-script-check` syntaktisch verifiziert; auf anode per `git pull` deployt (Dateien werden nur zur ISO-Bauzeit gelesen, kein laufender Dienst, kein Neustart nötig) und stichprobenartig gegengeprüft (erwartete Menüeintrags-Namen vorhanden).
## Konsequenzen
Kein vollständiger, realer Boot-Test (QEMU/Proxmox) dieser Änderung — anders als die ursprüngliche 01.08.2026-Korrektur, die für Mint real verifiziert wurde, sind die Fedora-Configs aktuell unbenutzter, bewusst ruhender Code (kein aktiver Pilotbetrieb auf Fedora). Sollte das Fedora-Backend reaktiviert werden, sollte der korrigierte Standardeintrag Teil der ohnehin nötigen Neuverifikation sein, nicht blind vorausgesetzt werden.
Dieses ADR schließt eine Lücke zwischen einer bereits getroffenen Entscheidung (ADR-0009) und ihrer tatsächlichen, vollständigen Umsetzung — keine neue fachliche Entscheidung. Es zeigt zugleich ein wiederkehrbares Muster für dieses Repo: ein sicherheitsrelevanter Fix in einer aktiv genutzten Variante (Mint) deckt nicht automatisch parallele, seltener berührte Varianten (Fedora) ab — bei künftigen sicherheitsrelevanten Korrekturen lohnt sich ein expliziter Check, ob es strukturell ähnliche, aber unabhängig gepflegte Geschwisterdateien gibt.
Details zur ursprünglichen Entscheidung: ADR-0009, `13-live-provisioning-boot.md`.