[Fli4l_dev] (Erst-)Installation von fli4l, Erzeugung von Bootmedien

Harvey hw234 at gmx.de
Di Okt 6 13:44:31 CEST 2026


Ich denke schon seit einiger Zeit darüber nach, wie man die 
(Erst-)Installation von fli4l einfacher und intuitiver machen könnte. 
Den Status Quo finde ich ziemlich archaisch und er legt die Hürde für 
neue User unnötig hoch.

## Status quo

`mkfli4l` erzeugt zwar Kernel, Rootfs, OPT-Archiv und Konfiguration, 
überlässt die Vorbereitung des Bootmediums aber weitgehend dem Benutzer.

Unter Linux erwartet `mkfli4l.sh --hdinstallpath` eine bereits 
partitionierte, formatierte und eingehängte FAT-Partition. Die 
Geräteerkennung verwendet Linux-spezifische Mechanismen und teilweise 
historisch gewachsene Annahmen.

Unter Windows existiert eine AutoIt-basierte Lösung. Sie kann Dateien 
auf ein vorhandenes FAT-Laufwerk kopieren und Syslinux installieren, 
aber keine ext4-Partitionen erzeugen oder ein flexibles Linux-Layout 
einrichten.

Die macOS-Unterstützung stammt im Wesentlichen noch aus der 
Diskettenzeit. Das alte Skript arbeitet mit Diskettenabbildern, 
veralteten Dateinamen und nicht mehr vollständig vorhandenen 
Hilfsprogrammen. Die vorhandenen Darwin-Binaries unterstützen nur 
Intel-Macs; für Apple Silicon wären native arm64- oder 
Universal-Binaries nötig.

WSL löst das Windows-Problem nicht überzeugend: Das direkte Durchreichen 
von USB- und SD-Medien ist eingeschränkt, benötigt Administratorrechte 
und häufig zusätzliche Software wie `usbipd-win`.

Die eigentliche HD-Installation erfolgt bislang über ein separates 
Setup-Medium. Der Router wird davon gestartet, der Benutzer meldet sich 
lokal, seriell oder per SSH an und startet `hdinstall.sh`. Das Verfahren 
funktioniert, setzt aber einiges an Vorwissen voraus.

## Grundidee

Statt auf jedem Betriebssystem Partitionierung, Formatierung und 
Bootloader-Installation unterschiedlich nachzubauen, könnte `mkfli4l` 
ein kleines, vorbereitetes Bootstrap-Abbild verwenden.

Dieses Abbild enthält eine FAT-Bootpartition von beispielsweise 256 MiB. 
Der restliche Datenträger bleibt zunächst unpartitioniert. Nach dem 
Schreiben kopiert `mkfli4l` die erzeugten fli4l-Dateien auf die 
FAT-Partition.

Auf dem Bootstrap-Medium befinden sich:

- Syslinux und MBR-Bootcode
- Kernel und Rootfs
- fli4l-Konfiguration und OPT-Archiv
- die für das gewählte System benötigten Treiber
- `sfdisk`, `mkfs.fat`, `mke2fs` und `mkswap`
- eine Beschreibung des gewünschten Partitionslayouts
- eine eindeutige Bootstrap-Kennung
- optional Dropbear für SSH und Diagnose

Es handelt sich also nicht um eine allgemeine Linux-Distribution, 
sondern um ein normales, startfähiges fli4l mit zusätzlichen Werkzeugen 
zur Fertigstellung des Datenträgers.

## Ablauf auf dem PC

Der Benutzer soll im Idealfall nur noch:

1. die fli4l-Konfiguration auswählen oder erstellen,
2. das Zielmedium auswählen,
3. die Löschwarnung bestätigen,
4. das Medium schreiben lassen,
5. den Router davon starten.

Die betriebssystemspezifischen Teile beschränken sich auf 
Geräteerkennung, Schreiben und Einhängen der FAT-Partition.

- Linux verwendet vorhandene Systemfunktionen und `dd`.
- Windows verwendet die vorhandene AutoIt-Oberfläche, `log2physdev.exe` 
und `dd.exe`.
- macOS verwendet `diskutil`, `hdiutil`, `/dev/rdiskN` und `dd`.

Für das Schreiben eines rohen Datenträgers werden unter allen 
Betriebssystemen erhöhte Rechte benötigt. Das ist technisch nicht 
vermeidbar. Zusätzliche Programme sollen dagegen nicht erforderlich sein.

## Fertigstellung im Router

Beim ersten Start läuft fli4l vollständig aus dem RAM. Es kann daher den 
noch freien Bereich seines Startmediums selbst einrichten.

Vorgesehen wäre:

1. Bootstrap-Kennung prüfen.
2. Startmedium über UUID oder `PARTUUID` eindeutig identifizieren.
3. Modell, Seriennummer und Größe protokollieren.
4. Im unpartitionierten Bereich OPT-, Swap- und Datenpartitionen anlegen.
5. Falls nötig kontrolliert neu starten, damit die neue 
Partitionstabelle sicher eingelesen wird.
6. Partitionen mit ext4 beziehungsweise Swap formatieren.
7. OPT- und Datenbereiche einrichten.
8. Installation prüfen und als abgeschlossen markieren.
9. Danach normal starten.

Die vorhandene FAT-Bootpartition muss dabei nicht gelöscht werden. Das 
reduziert das Risiko erheblich.

Die einzelnen Schritte sollten als Zustände gespeichert werden, etwa 
`partitioned`, `formatted` und `complete`. Nach Stromausfall oder 
Abbruch kann der Vorgang dann fortgesetzt werden.

## Headless-Systeme

Geräte wie eine PC-Engines-APU besitzen häufig keinen Bildschirm. Das 
ist für fli4l grundsätzlich nichts Neues: Bisher wurden solche Systeme 
über die serielle Konsole oder über den optionalen Dropbear-Server bedient.

Für das neue Verfahren sollten gelten:

- automatische Fertigstellung als Standard,
- Statusausgaben auf der seriellen Konsole,
- SSH als Diagnose- und manueller Zugangsweg,
- keine automatische Endlosschleife bei Fehlern,
- kein allgemeines Standardkennwort,
- bevorzugt Anmeldung mit öffentlichem Schlüssel,
- bei Fehlern bleibt das RAM-System erreichbar.

Die serielle Konsole bleibt wichtig, falls Netzwerkzuordnung, 
IP-Konfiguration oder Firewall nicht funktionieren.

## Hardwareprofile

Ein verpflichtendes neues Hardwareprofil wäre wahrscheinlich die nächste 
Einstiegshürde. Vorhandene Benutzer sollen deshalb ihre normale 
fli4l-Konfiguration weiterverwenden können.

Für Einsteiger könnten optionale Modellvorlagen angeboten werden:

- PC Engines APU
- PC Engines APU2/3/4
- Standard-PC x86_64
- virtuelle Maschine
- benutzerdefiniertes System

Eine Vorlage setzt nur sinnvolle Standardwerte für Architektur, 
Bootverfahren, serielle Konsole, Storage-, Netzwerk- und 
Hardwaretreiber. Danach bleibt alles eine normale fli4l-Konfiguration.

Für unbekannte Hardware kann ein begrenztes generisches Treiberpaket mit 
üblichen SATA-, NVMe-, USB-, MMC- und Ethernet-Treibern dienen. 
Sämtliche Linux-Treiber und Firmwaredateien einzupacken ist nicht 
sinnvoll: Allein die komprimierte Firmware würde einen großen Teil oder 
mehr als die gesamte 256-MiB-Bootpartition belegen.

Die schwierige Frage ist weniger der Treiber als die Bedeutung der 
Netzwerkanschlüsse. Linux kann eine Karte erkennen, aber nicht wissen, 
welcher Port LAN und welcher WAN sein soll. Bekannte Modellvorlagen 
können das vorbelegen; ansonsten müssen MAC-Adressen oder eine 
bestehende Konfiguration verwendet werden.

## Partitionslayout

Ein mögliches Standardlayout wäre:

- 256 MiB FAT für den Start
- bis zu 1024 MiB ext4 für OPT
- optional bis zu 256 MiB Swap
- ext4-Datenpartition mit dem verbleibenden Platz

Bei klassischem MBR stehen höchstens vier primäre Partitionen zur 
Verfügung und bei 512-Byte-Sektoren knapp 2 TiB adressierbarer Platz. 
Für größere Datenträger wäre GPT nötig. Dazu müssten BIOS-Boot über 
`gptmbr.bin`, Syslinux-Kompatibilität und gegebenenfalls UEFI gesondert 
umgesetzt und getestet werden.

## Sicherheit

Der kritischste Teil ist die Auswahl des Zielmediums. Das Programm muss 
deshalb:

- Systemdatenträger möglichst sicher ausschließen,
- Hersteller, Modell, Größe und Seriennummer anzeigen,
- immer das vollständige physische Gerät nennen,
- eine eindeutige Bestätigung verlangen,
- niemals pauschal `sda` annehmen,
- ausschließlich das mit der Bootstrap-Kennung versehene Medium 
automatisch erweitern.

Eine versehentliche Auswahl lässt sich nie vollständig ausschließen, 
aber deutlich schwerer machen.

## Ergebnis

Für neue Benutzer könnte sich der Vorgang auf „Konfiguration wählen, 
Medium auswählen, schreiben und starten“ reduzieren. Erfahrene Benutzer 
behalten Zugriff auf alle Einstellungen und einen manuellen 
Installationsmodus.

Offen zu diskutieren wären insbesondere:

- festes oder konfigurierbares Bootstrap-Layout,
- automatische oder bestätigungspflichtige Finalisierung,
- Umfang des generischen Treiberpakets,
- Umgang mit unbekannten Netzwerkanschlüssen,
- temporärer oder dauerhafter SSH-Zugang,
- MBR als erster Schritt oder sofortige GPT-Unterstützung,
- Pflege der Windows- und macOS-Writer,
- Apple-Silicon-Unterstützung.

Interessant wäre in diesem Zusammenhang auch, welche Hardware hier so im 
Einsatz ist und welche Version (x86 oder x86_64) genutzt wird.

Gruß
Harvey


Mehr Informationen über die Mailingliste Fli4l_dev