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

[Uwe Z.]

Moin!

Am 06.10.2026 um 13:44 schrieb Harvey:
> ## 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.

Das klingt sehr gut, insbesondere wenn man (aus welchem Grund auch 
immer) mal ein Bootmedium neu erstellen muss.

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

Auch das würde sicherlich gewisse Hürden abbauen, aber vor allem die 
Zeit deutlich verkürzen.

> 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.

U.a. hier hat (neben zeitweilig krankheitsbedingter Einschränkung des 
Nachdenkens) meine Antwort bisher am meisten Zeit gefressen.

Ganz offen gesprochen: Wenn ich mir selber einen Router baue, werde ich 
doch in der Lage sein, testweise den Netzwerkanschluß mal zu wechseln, 
wenn ich merke, dass die Zuordnung der LAN-Ports (noch) nicht meinem 
Wunsch entspricht.

Ich schaue auf dem RAM-System nach, welche LAN-Schnittstelle nun welche 
geworden ist, und passe die Konfiguration entsprechend an und reboote 
(und wechsele den Anschluß wieder).

Ggf. läßt sich dieses Verfahren auch für unbekannte Treiber anderer Art 
verwenden und quasi nur eine schlanke Diagnose (lspci?  Ich komme gerade 
nicht drauf) verwirklichen.

Bezüglich Zugriff auf das System (ich meine jetzt insbesondere die 
Ersteinrichtung) fallen mir folgende Möglichkeiten ein:
1.) die genannte serielle Konsole
2.) IPMI oder ein anderes Verfahren unabhängig vom Betriebssystem
3.) Bildschirm und Tastatur direkt angeschlossen
Daher sollte es doch irgendwie möglich sein, bei unbekannter Hardware 
eine Diagnose durchzuführen?

> ## 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

Wenn möglich würde ich den Swap nicht begrenzen (auch wenn man ihn nicht 
mag) und als zweite Partition einrichten. Dann kann man notfalls 
zwischen Opt und Data die Grenze verschieben.
Auch würde ich Opt nicht per se mit 1GB begrenzen, sondern höchstens 
Empfehlungen aussprechen.

Selbst bei einer 128GB SSD tun 32GB Opt nicht weh.

Eventuell macht es Sinn, auch GPT zu ermöglichen, ich müsste jetzt bei 
meinen Boards aber tatsächlich schauen, ob die UEFI booten könnten.

Auch finde ich die bisher vorhandene Möglichkeit, eine ältere Version 
als Recovery zu booten, sehr nützlich. Gäbe es die weiterhin?

> 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.

Klingt erstmal gut aus meiner Laiensicht.

> Offen zu diskutieren wären insbesondere:
> 
> - festes oder konfigurierbares Bootstrap-Layout,

Das überlasse ich euch, die sich damit besser auskennen.
Ich weiß nur aus einem anderen Projekt (XigmaNAS), das Erweiterungen an 
"Systempartitionen" nicht so einfach sind.

> - automatische oder bestätigungspflichtige Finalisierung,

Beim Schreiben auf dem PC oder auf dem FLI4L selbst? Bei letzterem ist 
doch der Drops fast schon gelutscht, da würde aus meiner Sicht eine 
"einfache" Bestätigung reichen, wenn sicher ist, das richtige Medium 
wurde erwischt.
Nur die Größen der Partitionen sollte man vorher noch bestätigen.

Auf dem PC würde ich ggf. mit doppelten und dreifachen Rückfragen und 
Checks arbeiten, damit nicht jemand versehentlich das Bootmedium (oder 
ein anderes) vom PC erwischt statt das für den Fli4l bestimmte. Hier 
sehe ich die größte Gefahr, vor allem wenn zufällig die Größen 
übereinstimmen.

> - Umfang des generischen Treiberpakets,

Alles für die Erstinbetriebnahme und ggf. die Identifikation unbekannter 
Hardware. Je mehr der Benutzer weiß, desto spezifischer kann hier ja 
schon aus der Konfig geschöpft werden, oder?

> - Umgang mit unbekannten Netzwerkanschlüssen,

Siehe oben.

> - temporärer oder dauerhafter SSH-Zugang,

Kann ich als "User/Password" Mensch schlecht beurteilen.

> - MBR als erster Schritt oder sofortige GPT-Unterstützung,

Uff. Ich bräuchte jetzt vermutlich kein GPT, aber ich bin ja nicht das 
Maß der Dinge.

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

2 Stück
ASRockRack C3558D4I Mainboard mit Version 4.1 x86_64.
Die haben 4x 1GBE Ports, Intel X553 (Treiber ixgbe).

Gruß
Uwe