Unix

BananaPi M5 rootdelay

Der BananaPi M5 kann von seiner SD-Kartte (mmc) oder von seiner internen SSD (emmc) gebootet werden, ein Booten von einer angeschlossenen USB-SSD ist nicht vorgesehen. Es geht aber doch, und zwar so:

Das Boot-Image wird auf die emmc geschrieben und exakt das gleiche Image auf die externe USB-SSD. Damit haben diese beiden Datenträger die gleiche UUID. In meinen Fällen habe ich dazei eines der Images von Armbian genommen, wo es mehrere zur Auswahl gibt (Debian, Ubuntu, minimal, Desktop, Server etc.)

Wird nun gebootet, erfolgt dies automatisch und immer von der emmc. Und hier, also auf der emmc, müssen im Verzeichnis /boot zwei Dateien geändert werden:

1. /boot/boot.cmd*

Ausschnitt /boot/boot.cmd auf der emmc:

# DO NOT EDIT THIS FILE
# Please edit /boot/armbianEnv.txt to set supported parameters

setenv scriptaddr "0x32000000"
setenv kernel_addr_r "0x34000000"
setenv fdt_addr_r "0x4080000"
setenv overlay_error "false"
# default values
# setenv rootdev "/dev/mmcblk1p1"
setenv rootdev "/dev/sda1"
setenv verbosity "1"
setenv console "both"
setenv bootlogo "false"
setenv rootfstype "ext4"
setenv docker_optimizations "on"

Trotz obiger Warnung habe ich diese Datei dann editiert: Die Zeile mit der mmcblk1p1 wurde auskommentiert und die fett markierte Zeile mit dem Eintrag /dev/sda1 hinzugefügt.

Ganz wichtig, sonst wirs nix:

Recompile with:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Also wie vorab gezeigt, wird die boot.cmd einmal neu kompiliert. Dauert nur Sekunden-Bruchteile.

2. /boot/armbianEnv.txt auf der emmc:

verbosity=1
console=both
overlay_prefix=meson
fdtfile=amlogic/meson-sm1-bananapi-m5.dtb
rootdev=UUID=759eca8c-35d7-4d78-aab7-67b40f019e95
rootfstype=ext4
extraargs=rootdelay=5
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

In der armbianEnv.txt wurde nur der fett markierte Eintrag hinzugefügt. Ohne diesen kam es ab und zu vor, dass trotzdem von der emmc gebootet wurde. Der Grund war, dass das System die USB-SSD noch nicht initialisiert hatte, weil diese zu langsam war. Also musste noch das rootdelay von 5 Sekunden dazu. Ob das wirklich nötig ist, hängt von der eingesetzten SSD bzw. dem USB-Adapter ab. Bei mir war's jedenfall notwendig.

In meinem Fall waren 10 Sekunden unnötig lang, aber 5 Sekunden zu kurz, so dass wieder von der emmc gebootet wurde. Mit 7 Sekunden lag ich dann richtig.

Und nur ganz nebenbei: Wenn ich OpenBSD auf dem BananPi M5 installiere, ist die Zeit zum Initialisieren von externen USB-SSD auch zu kurz und der Bootvorgang endet in der /bin/sh. Hier reicht es aber, ein simples "sleep 5" in die /etc/rc einzutragen, um die kleine Verzögerung zu realisieren.

OpenBSD sysupgrade beim BananaPi

Normalerweise ist ein System-Upgrade auf die nächste Version bei OpenBSD extrem einfach und narrensicher. Mit dem Tool sysupgrade läuft das perfekt durch.

Beim BananaPi M5 aber ist das ein wenig anders, sofern man den Rechner so eingerichtet hat, dass er OpenBSD von der internen eMMC bootet. Der Grund ist, dass diese eMMC beim Bootvorgang eine andere interne Bezeichnung hat als nachher im Betrieb.

Nachdem mir das klargemacht wurde, mache ich Systemupgrades auf dem BPiM5 nach folgendem Schema:

1. Herunterladen des neuen Installationskernel bsd.rd von openbsd.org und ins / des upzugradenden BananaPi kopieren.
2. Eintrag in /etc/boot.conf vornehmen: boot bsd.rd. Die /etc/boot.conf habe ich während der ersten Installation von OpenBSD erstellt. Dort habe ich nur set tty fb0 eingetragen. Das wurde jetzt durch boot bsd.rd ergänzt.
3. Jetzt neu Booten.
4. Das System bootet nun den neuen Kernel und startet ein Sysupgrade.
5. Nach dem Sysupgrade nicht neu booten, sondern eine Shell aufrufen. Das neue /etc-Verzeichnis ist jetzt noch unter /mnt/etc gemountet.
6. Da ausser ed zu diesem Zeitpunkt kein Editor verfügbar ist, überschreibe ich die boot.conf in /mnt/etc: echo "set tty fb0" > /mnt/etc/boot.conf. Dieser Eintrag wird benötigt, wenn die Ausgabe nach HDMI erfolgen soll, also wenn ein Monitor angeschlossen ist. Wird der BananaPi headless betrieben, ist eine boot.conf gar nicht mehr nötig.

Grundsätzlich könnte man auch bei sysupgrade so ähnlich vorgehen. Sysupgrade kann ja auch mit Parametern so aufgerufen werden, dass die neuen Dateipakete nicht gelöscht, sondern behalten werden und dass zwischen den Upgrade-Schritten nicht automatisch gebootet wird.

Dann muss zwischen den Schritten die boot.conf mehrfach geändert und dann mittels reboot manuell gebootet werden. Ist also etwas kniffeliger, aber ebenso möglich.