• eatmydata reduziert das exzessive "fsync()" von "dpkg". Das Filesystem syncen ist gänzlich unnötig, wenn man sich das
• ein Cache-Directory "downloads/apt.bookworm.amd64" schont die Debian-Server und erhöht die Geschwindigkeit — dies ist einer der Bereich, die Docker bis heute nicht gut gelöst hat.
• 28 Sekunden ist ein durchaus netter Wert

Anschließend hat man eine minimales Debian in einem Directory, welches man für

• TODO(Artikel schreiben) Linux Restore Stick
• TODO(Artikel schreiben) Teststick UEFI

einsetzen kann.

~/d/mkimage$ ls image.debootstrap.bookworm.amd64/
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
~/d/mkimage$ sudo du -hs image.debootstrap.bookworm.amd64/
182M	image.debootstrap.bookworm.amd64/

Auf den Geräten läuft ein selbst-kompilierter Kernel, basierend auf https://kernel.org. Das liegt daran, das der Standard-Debian-Kernel eher für Desktop- und Serverumgebungen gemacht ist, weniger für Embedded.

Also nehme ich jeweils einen aktuellen, stabilen Upstream-Kernel von kernel.org, füge AUFS für den hinzu. Anschließend werden noch jede Menge Patches mit Hilfe von quilt angewandt. Diesen haben oft diese Zwecke:

• Unterdrücken von harmlosen Kernel-Warnungen, die aber den Kunden beim Booten des Images verunsichern würden
• TODO Optimierungen des Linux mac80211 Layers und diverser WLAN-Treiber (z.B. Atheros) zum besseren Roaming
• Geschwindigkeitsoptimierungen für ein schnelleres Booten / Filesystem

Die Kernel-Sourcen werden direkt von kernel.org heruntergeladen und in "downloads/" gecacht.

Neben den Patches gibt es auch noch in "*.kconfig" Files eine Kernelkonfiguration. Die wichtigste ist natürlich "default.kconfig". Sie macht nur Dinge an, die wir brauchen. Ein Beispiel: Debian hat "Hot CPU Swap" an – aber das wird bei Industrie-Geräten nie der Fall sein. Man müßte das Gerät komplett zerlegen, um an die CPU zu kommen.

Neben der Default-Konfiguration gibt es noch für jedes unterstützte Gerät eine "device-XXXX.kconfig" Datei, welches Treiber für dieses spezifische Gerät aktiviert. Ein Beispiel:

#00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 11)
CONFIG_DRM_I915=m

#00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 11)
CONFIG_USB_XHCI_HCD=y

Es gibt (oder gab) noch diverse externen Kernel-Module, beispielsweise zur Hardware-Erkennung, BIOS-Updates, Penmount-Treiber, diverse externe USB-Geräte.

• die schnelle Kompilationszeit kommt daher, das viele Kernel-Subsysteme erst gar nicht kompiliert werden. Warum sollte ein Image für die Industrie Treiber für Graphics-Tablets oder DVB-S (Satelittenfernsehen) habe?

Wer jemals ein Docker-Image auf Debian-Basis erstellt hat, wird sich evtl. die Augen reiben: wie kann man ein Image in gerade mal 23 Sekunden bauen? Allein die Docker-Zeile "apt-get update; apt-get install foo bar baz; apt-get clean" braucht wesentlich länger?

Der Trick ist hier ist:

• einerseits die Installation von "eatmydata" ins Image hinein (siehe Zeile (eatmydata) oben. Es wird dann beim Installieren von ".deb"-Paketen kein "fsync()" or "open(...,O_SYNC)" ausgeführt.
• manuelles Dependency-Resolving. Hier in Beispiel: um BlueZ (den Linux-Bluetooth-Daemon) zu installieren, braucht man vorher einige Libraries. Statt "apt" das herausfinden zu lassen, finde ich es einmalig heraus und fordere die explizit. Die Datei "base/bluez" sieht dann z.B. so aus:

need base/user                               (ref:user)
need base/systemd
need base/lib-glib                           (ref:glib)

install_debian_deb bluez                     (ref:bluez)
install_debian_deb libbluetooth3             (ref:lib1)
install_debian_deb libdw1
install_debian_deb libasound2
install_debian_deb libasound2-data
install_debian_deb libreadline8
install_debian_deb readline-common           (ref:lib7)

do_run()                                     (ref:dorun)
{
    mkdir -p ${IMAGE_DIR}/etc/systemd/system/bluetooth.service.d/
    copy_file less-services.conf etc/systemd/system/bluetooth.service.d/  (ref:dropin)

    ...
    in_image adduser --quiet dlog bluetooth >/dev/null    (ref:adduser)
}

Das bedeutet im einzelnen:

• bevor "base/bluez" ausgeführt werden kann, muss (Zeile (user)) ein Standard-User angelegt werden. Das liegt daran, das wir diesen User mit "addgroup" in die Gruppe "bluetooth=" aufnehmen wollen (Zeile (adduser)).
• dann brauchen wir noch systemd vorher im Image, da wir ein Drop-In Konfigurationsfile installieren, welches Teile des Debian-BlueZ-Unit überschriebt (Zeile (dropin)).
• BlueZ braucht wie viele andere Programm die glib. Statt also alle .deb unten anzuführen, die glib installieren, habe ich das in ein eigenes "base/lib-glib" ausgelagert (Zeile (glib)).
• "need" ist übrigens eine Shell-Funktion, definiert in "bin/run". Dasselbe gilt für "install_debian_deb" und "in_image".
• nun wird BlueZ selbst in Zeile (bluez) und alle benötigten Libraries installiert (Zeilen (lib1) bis (lib7)).
• Wenn alle Debian-Pakete installiert sind, wird die Funktion "do_run" in Zeile (dorun) aufgerufen. Sie kann beliebige Programme aufrufen, einmal außerhalb des neu erstellten Images, aber auch innerhalb mit Hilfe von "in_image". Außerdem sind diverse Environment-Variablen wie "$RUN_HOME", "$IMAGE_DIR" und "$DATA_DIR" definiert.

~/d/mkimage$ ls image
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
~/d/mkimage$ sudo du -hs image
639M	image

Diese Image kann nun mit "cd image; tar cvzf ../combined-linux.tar.xz ." eingepackt werden. Dieses File würde man dann auf einen TODO(Artikel schreiben) "Linux Restore Stick" kopieren und damit Geräte initialisieren.

Man kann es auch mir "rsync" direkt per Ethernet oder WLAN auf ein Gerät syncen — das ist erheblich schneller: nach wenigen Sekunden ist das neue erstellte Image testbar.