xinionos/docs/decisions/ADR-0002-startverfahren-und-ruecksprung.md

# ADR-0011 — systemd-boot trägt den Rücksprung, der Selbstprüflauf entscheidet ihn

**Stand:** Angenommen, 17.08.2026 · **Entscheidet:** CIO Thomas Reitz
**Setzt um:** `ADR-0004` (A/B-Wurzel) · **Betrifft:** Abbildbau, Updatekanal, offene Frage O-8
**Nachweis steht aus** — die Punkte unter „Was am Gerät zu bestätigen ist"

---

## Worum es geht

`ADR-0004` verspricht einen Rücksprung, der mehr kann als „bootet nicht": Nach dem Umschalten
bekommt die neue Fassung eine begrenzte Zahl von Versuchen, gilt erst nach einem bestandenen
**Selbstprüflauf** als bestätigt, und läuft der Zähler ab, kehrt das Gerät **von selbst** zur
vorherigen Wurzel zurück.

Das ist eine Zusage über Zähler, Schwellen und Zustände — also über Mechanik, die entweder korrekt
ist oder still versagt. Und sie versagt an einer unangenehmen Stelle: **Ein Rücksprung, der nicht
funktioniert, fällt erst auf, wenn man ihn braucht.**

Diese Entscheidung legt fest, womit er gebaut wird.

## Die Entscheidung

**Der Startvorgang läuft über systemd-boot mit dessen Automatic Boot Assessment. Der
Selbstprüflauf hängt vor `boot-complete.target`.**

Der Grund ist, dass genau diese Mechanik dort bereits existiert und gepflegt wird:

| Was ADR-0004 verlangt | Was systemd-boot mitbringt |
|---|---|
| begrenzte Zahl von Startversuchen | Zähler im Dateinamen des Starteintrags — `…+3.conf` |
| Herunterzählen bei jedem Versuch | erledigt der Startverwalter selbst, vor dem Kern |
| Bestätigung erst nach bestandener Prüfung | `systemd-bless-boot` löscht den Zähler — und läuft erst nach `boot-complete.target` |
| Rückfall nach erschöpften Versuchen | erschöpfte Einträge werden ans Ende sortiert |

Unser Anteil daran ist eine einzige Unit: der Selbstprüflauf, der **vor** `boot-complete.target`
laufen muss und von ihm **benötigt** wird. Fällt er durch, wird das Ziel nie erreicht, der Zähler
nie gelöscht — und der dritte Fehlversuch stuft die Fassung ab.

> **Der eigentliche Gewinn ist, was wir dadurch nicht bauen.** Ein selbstgeschriebener Startzähler
> in einer Umgebungsvariablen des Startverwalters ist erfahrungsgemäß genau die Stelle, an der
> Rücksprünge versagen: Er wird bei einem unsauberen Abschalten nicht zurückgesetzt, er verzählt
> sich bei einem Neustart aus der laufenden Sitzung, und niemand merkt es, weil der Normalbetrieb
> davon nichts sieht. Bei einem Produkt, dessen Verkaufsargument der funktionierende Rückweg ist,
> ist geerbte und gepflegte Mechanik mehr wert als eigener Code.

## Was daraus für den Aufbau folgt

**Kern und Startabbild liegen auf dem EFI-Bereich.** systemd-boot liest keine Linux-Dateisysteme;
was es starten soll, muss auf dem EFI-Bereich liegen. Je Wurzel ein eigenes Verzeichnis, also zwei
Sätze aus Kern und Startabbild. Das ist der Grund, warum der EFI-Bereich in ADR-0004 mit einem
Gigabyte großzügiger bemessen ist als üblich.

**Der Selbstprüflauf wächst mit dem Produkt.** Heute prüft er, was es gibt: richtige Wurzel
eingehängt, Bestandsbereich vorhanden, Dienste gestartet. Später kommen die Punkte aus ADR-0004
dazu — Datenbank antwortet, jede Aufgabenklasse ist bedienbar, der Wissensspeicher ist erreichbar.
**Die Verdrahtung ändert sich dabei nicht**, nur die Prüfliste. Das ist der Grund, ihn früh zu bauen.

**Und er braucht einen Prüfschalter.** Ein Rücksprung, den man nicht auslösen kann, ist nicht
prüfbar. Deshalb bringt der Selbstprüflauf einen ausdrücklichen Weg mit, absichtlich
durchzufallen — sonst lässt sich die Abnahmebedingung nicht messen.

## Was am Gerät zu bestätigen ist, bevor diese Entscheidung als belegt gilt

Vier Punkte, und keiner davon lässt sich herleiten:

**Greift der Rückfall wirklich?** Drei Fehlversuche auf Wurzel B müssen das Gerät ohne Zutun nach A
bringen. Das ist die Abnahmebedingung, alles andere ist Vorarbeit.

**Trägt die signierte Startkette?** Ubuntu startet regulär über GRUB mit vorgelagertem Prüfglied.
Ob systemd-boot dort mit eingeschaltetem Secure Boot sauber läuft, ist am Gerät zu prüfen. Fällt
das negativ aus, ist der zweite Weg aus der Bewertung unten zu nehmen — die übrige Bauweise bleibt.

**Überlebt der Tresorschlüssel den Fassungswechsel?** Bindet er an den Sicherheitsbaustein, hängt er
an einer Messung des Startzustands — und der ändert sich mit dem Startverwalter. Das ist die offene
Frage O-8, und sie wird durch diese Entscheidung **berührt, nicht gelöst**.

**Verhält sich ein erschöpfter Eintrag wie erwartet?** Dass abgestufte Einträge ans Ende sortiert
werden, ist dokumentiert. Wie sich das mit einem ausdrücklich gesetzten Vorgabeeintrag verträgt,
gehört nachgesehen und nicht angenommen.

> Bis diese vier Punkte gemessen sind, gilt für diese Entscheidung dieselbe Regel wie für alles
> andere in diesem Produkt: **Sie ist begründet, nicht belegt.**

## Die verworfene Alternative

**GRUB mit eigenem Zähler.** Ubuntus Standardweg bliebe unangetastet, die signierte Kette
funktioniert nachweislich, und die Mechanik wäre über `GRUB_DEFAULT=saved` und einen Zähler in der
Umgebungsdatei des Startverwalters aufgebaut.

Der Vorzug ist real und war der Grund, überhaupt abzuwägen: Bei eingeschaltetem Secure Boot ist das
der Weg, der garantiert läuft.

Dagegen steht, dass **der Zähler dann unser Code ist** — und zwar Code, der bei jedem unsauberen
Abschalten, jedem Neustart aus der laufenden Sitzung und jedem Stromausfall das Richtige tun muss.
Getestet wird er nur, wenn jemand einen Rücksprung auslöst, also fast nie. Ein stiller Fehler darin
zeigt sich zum ersten Mal an dem Tag, an dem ein Kunde ihn braucht.

**Fällt die Secure-Boot-Prüfung negativ aus, wird diese Alternative wieder aufgenommen** — dann
allerdings mit der ausdrücklichen Auflage, den Zähler gegen unsauberes Abschalten zu prüfen, nicht
nur gegen den Normalfall.