[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