admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
platform-docs/adr/0016-grub-standardeintrag-luecken-geschlossen.md
Thomas Stallinger a4cf9590c8 docs: ADR-0016 GRUB-Standardeintrag-Lücken geschlossen 
Dokumentiert den tuxflotte-installer-Commit 517c2de: die 01.08.2026-
Sicherheitskorrektur (Standard = lokal booten statt Auto-Install, siehe
ADR-0009) war nicht vollständig umgesetzt - Fedoras GRUB-Configs
(EFI-BOOT-grub.cfg, boot-grub2-grub.cfg) defaulteten weiterhin echt auf
den unbeaufsichtigten Install-Eintrag, Mints nicht-EFI-Zweig hatte gar
keinen lokalen-Boot-Eintrag (vermutlich unerreichbar, trotzdem
abgesichert). Gefunden bei der Live-Gegenlese aller ADRs gegen anode.

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

4.4 KiB
Raw Blame History

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 (boot-grub.cfg/isolinux-live.cfg), 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.