From hw234 at gmx.de Thu Oct 1 10:47:04 2026 From: hw234 at gmx.de (Harvey) Date: Thu, 1 Oct 2026 10:47:04 +0200 Subject: [Fli4l_dev] Neue fli4l Testversionen, Webseitenzugriff In-Reply-To: <101slb6$3cg67$1@vm-news.spline.inf.fu-berlin.de> References: <101slb6$3cg67$1@vm-news.spline.inf.fu-berlin.de> Message-ID: <119l6m8$hgq5$1@vm-news.spline.inf.fu-berlin.de> llo zusammen, es gibt einen neuen Build ?? Auch dieses Mal gibt es wieder neue Kernel, Fixes und Performanceoptimierungen. Changelog siehe unten. Der Download ist an der üblichen Stelle zu finden: https://www.fli4l.de/doku.php?id=fli4l:download:developerversion:start#entwicklerversion_41 Gruß Harvey Changelog fli4l: =============== Zeitraum: 22.09.2026 bis 29.09.2026 Revisionen: 1be180fa6 bis e56ad77bd (jeweils einschließlich) OpenVPN ------- * Automatisch gestartete OpenVPN-DCO-Clients werden nun überwacht und nach einem unerwarteten Prozessende automatisch neu gestartet. WebGUI-Aktionen wie Stop und Reload bleiben davon unberührt. Doppelte Starts sowie die Verwendung veralteter PID- und Lock-Dateien werden verhindert. (1be180fa6) * Zertifikate werden beim Erstellen einer Distribution auf ihre Gültigkeit geprüft. Vor einem Ablauf innerhalb von 30 Tagen wird gewarnt; ungültige oder abgelaufene Zertifikate führen zu einem Abbruch. (89b11b195, 0e70c0233) * OpenVPN-Server mit dynamischen, verbindungsabhängigen lokalen Adressen werden erst gestartet, wenn die Adresse verfügbar ist. Änderungen der Adresse führen zu einem kontrollierten Neustart; die zugehörigen Firewall-Einträge werden synchron zur Instanz verwaltet. (8184d96e7) WebGUI ------ * Die ARP-Übersicht berücksichtigt nun den Zustand aus der IPv4-Nachbartabelle. Veraltete Einträge werden gelb dargestellt. Adressen, deren MAC-Adresse auf derselben Schnittstelle unter einer anderen Adresse bestätigt wurde, werden als veraltet beziehungsweise doppelt gekennzeichnet. (c0ef3c72d) * Die ARP-Übersicht wird wieder numerisch nach IPv4-Adresse sortiert. (e56ad77bd) Kernel ------ * Aktualisierung der Kernel auf Version 7.2.8 und 6.18.54. (7fe81ffc7) Hardware-Unterstützung ---------------------- * Der Start des Watchdogs auf PC-Engines-APU2-Systemen wurde korrigiert. Das Watchdog-Modul wird wieder zuverlässig geladen und der Kernel-Thread nicht mehr mit dem Watchdog-Daemon verwechselt. (af16df1a1) * Hardware-spezifische Watchdog-Treiber werden nicht mehr geladen, wenn HWSUPP_WATCHDOG deaktiviert ist. (742f6c96f) * Ein durch den APU2-Watchdog verursachter Neustart wird beim nächsten Bootvorgang erkannt und als Warnung im WebGUI angezeigt. (90455adac) * Watchdog-Timeout und Prüfintervall können nun über HWSUPP_WATCHDOG_TIMEOUT und HWSUPP_WATCHDOG_INTERVAL eingestellt werden. Die Standardwerte betragen 20 beziehungsweise eine Sekunde. (1c2ee4540, 4519092b8) Festplatteninstallation ----------------------- * Die Festplatteninstallation verwendet nun sfdisk mit MiB-ausgerichteten Partitionen anstelle des bisherigen CHS-basierten fdisk-Ablaufs. * OPT- und Datenpartitionen werden mit ext4 statt ext3 angelegt. Größenbeschränkungen der Partitionen und des MBR-Formats werden berücksichtigt. * Die Kompatibilität zum Syslinux-MBR bleibt erhalten. Passende Bootdateien können direkt von einem HD-Installationsmedium übernommen werden. * Installationsmeldungen und die deutsche, englische und französische Dokumentation wurden überarbeitet. (268a97725) From hw234 at gmx.de Tue Oct 6 13:44:31 2026 From: hw234 at gmx.de (Harvey) Date: Tue, 6 Oct 2026 13:44:31 +0200 Subject: [Fli4l_dev] (Erst-)Installation von fli4l, Erzeugung von Bootmedien Message-ID: <11a2muv$100gm$1@vm-news.spline.inf.fu-berlin.de> 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 From nelson at anires.de Wed Oct 7 19:46:15 2026 From: nelson at anires.de (Nelson Matias) Date: Wed, 7 Oct 2026 19:46:15 +0200 Subject: [Fli4l_dev] (Erst-)Installation von fli4l, Erzeugung von Bootmedien References: <11a2muv$100gm$1@vm-news.spline.inf.fu-berlin.de> Message-ID: <20261007194615.00000260@anires.de> Hallo Harvey, am Tue, 6 Oct 2026 13:44:31 +0200 schrieb Harvey in spline.fli4l.dev >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. Wenn das ganze eh schon mal überarbeitet werden soll, dann finde ich sollte auch zukunftsorientiert gearbeitet werden. Viele Systeme sind jetzt schon nur noch per UEFI bootbar. Ich finde Fli4l sollte auch auf dieses System gehoben werden. Das ist vor kurzem auch beim Eisfair passiert. Vielleicht kann hier von deren Erfahrung profitiert werden. Bootstrap-Layout: Ich finde das vorgeschlagene Layout ist gut. Jedes Gerät sollte mindestens über einen 4GB Datenträger verfügen. Somit sollte hier genug Platz vorhanden sein. Finalisierung: Die Finalisierung sollte automatisch erfolgen. Mit einem Opt-in um den Nutzer die Möglichkeit bei Unsicherheit das nochmals bestätigen zu können. Aber bei einem headless System sollte das nicht sein. generisches Treiberpaket: Vielleicht könnte es ja wählbare Pakete geben. Der Nutzer wählt den oder die Hersteller der verschiedenen Komponenten aus und es werden alle Treiber dieses Herstellers eingepackt. Solange es so gelöst ist könnte ein entsprechender Hinweis auf der Weboberfläche und beim Konsolenlogin angezeigt werden, welche Treiber tatsächlich genutzt werden und wo diese gezielt eingestellt werden müssen um beim Update Übertragungszeit zu sparen. Oder es bleibt einfach so. unbekannte Netzwerkanschlüsse: Auch hier würde ich eine Meldung darüber ausgeben, aber diese unkonfiguriert lassen. SSH-Zugang: Um der Sicherheit willen sollte es möglich sein den SSH-Zugang dauerhaft einrichten zu können. Das sollte auch gleich mit einem Schlüsselpaar passieren. Natürlich kann das dann nur vom Konfigurations-PC aus gehen, aber man kann dem Nutzer ja auch den Schlüssel nochmals ausdrücklich an die Hand geben, damit er diesen zusätzlich sichert. Hier dann auch nochmals auf die Doku verweisen, wo nochmals auf die Schlüssel hingewiesen wird und wie man diese einrichtet. (Verweis auf ein Howto?) MBR und/oder GPT: Auch hier würde ich schon auf GPT setzen. Ich sehe keinen Nachteil darin. Pflege der Windows- und macOS writer Da kann ich leider nicht helfen. Apple-Silicon-Unterstützung Auch hier mangelt es mir an Wissen um Helfen zu können. Ich nutze ein PCEngines APU2 für meinen Fli4l und das x86_64 system -- Gruß Nelson