Seminar Libreboot Versionswechsel und Release-Management

Ein neues Libreboot-Release wird nicht allein wegen einer höheren Versionsnummer eingeführt. Das Seminar entwickelt eine nachvollziehbare Änderungsanalyse, reproduzierbare interne Artefakte, Regressionstests, Pilotierung und einen belastbaren Rückfallentscheid.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Releaseänderungen nach Board, Payload, Sicherheit und Toolchain filtern
• Betroffene Geräteklassen und erforderliche Tests bestimmen
• Interne ROM-Pakete mit Quellstand, Hashwerten und Freigaben erzeugen
• Einführung, Zurückstellung oder Überspringen sachlich entscheiden

Zielgruppe

Plattformbetrieb, Release-Management, Firmware-Entwickler, QA, IT-Service und technische Governance.

Voraussetzungen

Libreboot-Grundkenntnisse sowie Erfahrung mit Build- oder Flashprozessen. Ein vorhandener freigegebener Stand und ein Kandidatenstand sind für Übungen erforderlich.

Seminarinhalte

Kapitel 1: Releasebewertung und Änderungsanalyse

Inhaltsübersicht: Relevanz filtern; Testumfang ableiten; Entscheidung dokumentieren

1. Schritt 1 – Relevanz filtern: Boardunterstützung, Sicherheitskorrekturen, Toolchain, Payloads, Vendor-Dateien und bekannte Regressionen werden pro Geräteklasse bewertet.
2. Schritt 2 – Testumfang ableiten: Aus den Änderungen werden Pflicht-, Stichproben- und Regressionstests sowie betroffene Pilotgeräte bestimmt.
3. Schritt 3 – Entscheidung dokumentieren: Einführen, zurückstellen oder überspringen wird mit Risiko, Nutzen und nächstem Prüftermin begründet.

Kapitel 2: lbmk-Arbeitsumgebung und Quellstand

Inhaltsübersicht: Buildhost vorbereiten; Quellstand festhalten; Umgebung testen

1. Schritt 1 – Buildhost vorbereiten: Unterstütztes Betriebssystem, Pakete, Speicherplatz, Netzwerkzugriff, Benutzerrechte und getrennte Arbeitsverzeichnisse werden eingerichtet.
2. Schritt 2 – Quellstand festhalten: Repository, Commit, lokale Änderungen, Submodule und verwendete Konfigurationsdateien werden eindeutig dokumentiert.
3. Schritt 3 – Umgebung testen: Werkzeuge, Compiler, Downloadpfade und ein kleiner Referenzbuild werden geprüft, bevor produktive ROMs erzeugt werden.

Kapitel 3: ROM-Build, Artefakte und Prüfsummen

Inhaltsübersicht: Build ausführen; Artefakte prüfen; Hashwerte veröffentlichen

1. Schritt 1 – Build ausführen: Ein einzelnes Boardtarget wird mit protokollierter Umgebung erzeugt; Fehler werden am ersten ursächlichen Schritt analysiert.
2. Schritt 2 – Artefakte prüfen: Dateinamen, Größe, enthaltene Payloads, Konfiguration, CBFS-Inhalt und erwartete Boardvarianten werden kontrolliert.
3. Schritt 3 – Hashwerte veröffentlichen: Freigegebene ROMs erhalten Prüfsummen, Buildprotokoll, Quellstand und eindeutige Zuordnung zum Zielgerät.

Kapitel 4: Reproduzierbarkeit und Build-Nachweis

Inhaltsübersicht: Einflussgrößen erfassen; Zweitbuild erzeugen; Abweichungen erklären

1. Schritt 1 – Einflussgrößen erfassen: Zeitstempel, Toolchain, Quellarchive, lokale Patches, Umgebungsvariablen und nicht deterministische Schritte werden identifiziert.
2. Schritt 2 – Zweitbuild erzeugen: Ein zweiter Build in sauberer Umgebung wird mit identischer Definition ausgeführt und byteweise verglichen.
3. Schritt 3 – Abweichungen erklären: Unterschiede werden lokalisiert, klassifiziert und entweder beseitigt oder im Freigabenachweis begründet.

Kapitel 5: Testmatrix für Firmware und Zielhardware

Inhaltsübersicht: Prüfbereiche definieren; Varianten abdecken; Erwartungen festlegen

1. Schritt 1 – Prüfbereiche definieren: Kaltstart, Warmstart, Payload, Datenträger, USB, Netzwerk, Grafik, Audio, Suspend, Akku und Erweiterungskarten werden erfasst.
2. Schritt 2 – Varianten abdecken: Boardrevision, RAM-Bestückung, Display, Massenspeicher, Payload und Betriebssystem werden nach Risiko kombiniert.
3. Schritt 3 – Erwartungen festlegen: Jeder Test erhält Vorbedingung, Schrittfolge, Sollresultat, Beleg und Schweregrad eines Fehlers.

Kapitel 6: Regressionstests und Fehlerlokalisierung

Inhaltsübersicht: Referenzvergleich aufbauen; Änderung eingrenzen; Freigabe blockieren

1. Schritt 1 – Referenzvergleich aufbauen: Letzter freigegebener Stand und Kandidat werden auf identischer Hardware mit derselben Testmatrix verglichen.
2. Schritt 2 – Änderung eingrenzen: Quellstand, Konfiguration, Payload und Hardware werden einzeln variiert, um den ersten fehlerhaften Stand einzugrenzen.
3. Schritt 3 – Freigabe blockieren: Kritische oder ungeklärte Regressionen verhindern den Rollout; Ausnahmen benötigen dokumentierte Risikofreigabe.

Kapitel 7: Releasepaket und interne Freigabe

Inhaltsübersicht: Artefakte erzeugen; Vier-Augen-Prüfung durchführen; Paket versiegeln

1. Schritt 1 – Artefakte erzeugen: ROMs, Prüfsummen, Buildprotokolle, Konfigurationsstände und Recovery-Dateien werden als geschlossenes Paket erstellt.
2. Schritt 2 – Vier-Augen-Prüfung durchführen: Boardzuordnung, Dateigröße, Payload, Hashwert, Vendor-Dateien und Freigabestatus werden unabhängig kontrolliert.
3. Schritt 3 – Paket versiegeln: Freigegebene Dateien werden schreibgeschützt abgelegt; nachträgliche Änderungen erzeugen zwingend eine neue Version.

Praxisübungen

Ein Kandidatenrelease wird gegen einen freigegebenen Bestand bewertet. Daraus entstehen Testumfang, internes ROM-Paket, Pilotentscheidung, Freigabevermerk und dokumentierte Rollbackschwelle.

Methodik

Fachliche Kurzvorträge, Live-Demonstrationen, geführte Laborphasen, Checklisten und dokumentierte Kontrollpunkte wechseln sich ab. Schreiboperationen am Firmware-Flash erfolgen ausschließlich an freigegebenen Übungsgeräten mit vorhandenem Original-ROM und vorbereitetem Recovery-Weg.