Thomas Stallinger
4b188b8f3a
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>
4.6 KiB
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:
13-live-provisioning-boot.mdwidersprach sich selbst — ein älterer, nie nachgezogener Abschnitt behauptete weiterhin unkorrigiert das Gegenteil (behoben, siehe Commit vom 12.08.2026, kein eigenes ADR).- Beim Nachschauen der tatsächlichen Boot-Configs in
tuxflotte-installerzeigte sich:grub/mint-boot-grub.cfghat 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, weilscripts/build.shfür BIOS-Boot tatsächlichisolinuxeinsetzt, nicht diesen GRUB-Zweig. - 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ändertset 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 samtset defaultwie 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.