Lorem Ipsum, mehr gibt's noch nicht.
Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum
Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum
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:
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.
Einige Betriebssysteme wie NetBSD und eingeschränkt auch OpenBSD benötigen beim Raspberry 4B und 5 ein Start-Medium mit der EDK-Firmware. Damit wird der Raspberry via UEFI gebootet und kann danach das Betriebssystem laden. So weit, so gut.
Anfangs hatte ich die EDK-Firmware immer auf eine kleine SD-Karte geschrieben und diese in den Kartenslot des Rechners gesteckt. Leider ist es dann ab und zu vorgekommen, dass das Medium irgendwann beschädigt war und der Raspi nicht mehr bootete.
Daher habe ich mir aus China 10 Stück winzige SSD mit 16 GB besorgt, um darauf die EDK-Firmware zu installieren. Wo immer es ging, habe ich allerdings die Firmware auf eine kleine Partition der SSD mit dem Betriebssystem zusammen untergebracht. Die Vorgehensweise ist für beide Fälle quasi identisch.
Prinzipiell kann die Aktion unter jedem beliebigen Betriebssystem erledigt werden. Ich persönlich machs aber am liebsten unter Linux, und diesen Weg beschreibe ich hier auch:
1. Auf der SSD wird eine mit gdisk eine neue, leere GUID Partitions-Tabelle (GPT) erstellt. Dies erfolgt in gdisk mit dem Befehl o.
2. Anschliessen wird, immer noch in gdisk, die erste Partition mit n erzeugt. Ich wähle meist eine Größe von 500MB ... 1 GB. Als Partitions-Typ wird MS-basic-date (0700) gewählt. Erstelle ich eine reine Boot-SSD, gibt es noch eine zweite Partition in der gleichen Größe, ebenfalls mit Typ 0700. Diese nehme ich als Backup, wenn die erste Partition beschädigt werden sollte. Ist tatsächlich schon passier. Auf einer SSD mit dem kompletten OS verzichte ich darauf und lege die weiteren Partition nach Bedarf an, meist eine Swap- und eine Systempartition.
3. Nach dem Speicher verlasse ich gdisk und formatiere die EDK-Partition mit mkfs.fat.
4. Zur Kontrolle starte ich nun gparted und schaue nach, ob die Boot-Partition für die EDK-Firmware die Markierungen esp und boot hat. Ist dies nicht der Fall, werden sie in gparted gesetzt. Das war's dann auch in gparted.
5. Abschliessend wird die Partition gemountet und die aktuele Version der EDK-Firmware wird darauf kopiert. Die Firmware hole ich mir bei Github: EDK-Firmware für Raspberry 4 bzw. EDK-Firmware für Raspberry 5
Das war also die grobe Beschreibung für diese Prozedur. Ist, wie man sieht, nicht schwierig, aber weil ich's nicht jeden Tag mache, hab ich's mal kurz dokumentiert.
Aus dem BananaPi-Forum von sinovoip:
Einige arm64 SOC-Rechner wechseln nach dem Zufallsprinzip beim Systemstart die MAC-Adresse der Netzwerkschnittstelle. Mag für manche Anwendungen gut und sicherer sein, ist aber von Übel bei festen IP-Adressen über einen DHCP-Server.
Dieses Verhalten kann unter Linux sehr einfach abgestellt werden: Unter /etc/udev/rules.d wird eine neue Datei mit dem Namen 75-static-mac erstellt mit dem Inhalt:
ACTION=="add", SUBSYSTEM=="net", ATTR{dev_id}=="0x0", RUN+="/usr/bin/iplink set dev %k address XX:XX:XX:XX:XX:XX"
Dabei wird XX:XX:XX:XX:XX:XX mit der aktuellen MAC-Adresse der Schnittstelle ersetzt. Oder, sofern man sich ein paar MAC Adressen gemerkt hat, einfach eine davon aussuchen.
Mit den locales auf der Console stehe ich bei OpenBSD immer ein bisschen auf dem Kriegspfad. Da sind so viele Parameter, die da hinein spielen, dass ich wohl den Überblick verloren habe.
Nach vielen Versuchen, Fehl- und Rückschlägen habe ich nun eine Konfiguration, mit der ich leben kann. Perfekt ist sie aber leider noch immer nicht.
Als erstes habe ich mich entschieden, die TERM-Einstellungen in der /etc/ttys nicht zu ändern, sondern auf der Originaleinstellung zu belassen, also auf vt220.
Sollte ich ausnahmsweise mal eine andere Einstellung benötigen, beispielsweise für den midnight-commander, so mach ich das über das Setzen von $TERM in einem Script.
Meine locale Einstellungen lege ich in der ~/.profile fest, und zwar wie folgt:
export LANG=de_DE.UTF-8
export LC_ALL=" "
Die deutsche Tastaturbelegung wird in der /etc/kbdtype mit de.nodead gesetzt.
Das Kommando locale gibt nun das hier aus:
LANG=de_DE.UTF-8
LC_COLLATE=" "
LC_CTYPE=" "
LC_MONETARY=" "
LC_NUMERIC=" "
LC_TIME=" "
LC_MESSAGES=" "
LC_ALL=\
"locale -m" sagt: UTF-8 und "locale charmap" zeigt US-ASCII.
Damit habe ich FAST alle benötigten Sonderzeichen und Umlaute auf der Tastatur - bis auf den € und den ¢. Daran muss ich wohl noch arbeiten. Unter Xorg sind natürlich alle Zeichen vorhanden.
Arm64 Rechner wie der RaspberryPi oder der BananaPi werden ja von OpenBSD recht gut unterstützt. Probleme hatte ich aber mit RaspberryPi 4B und BananaPi M5, wenn OpenBSD von einer USB-SSD booten sollte.
Dabei kam es vor, dass OpenBSD bei jedem Rechnerstart hängen blieb, weil fsck einen nicht behebbaren Fehler meldete. Sehr ärgerlich, besonders wenn die Maschinen headless betrieben werden.
Dann musste der Aufruf einer Emergeny-Shell (sh) bestätigt werden. Wurde dort ein manueller fsck gestartet, lief der ohne Fehler durch und der Rechner bootete dann durch. Es hat sogar gereicht, einfach die sh zu bestätigen und dann sofort wieder zu verlassen: Auch dann bootete der Rechner durch.
Durch Diskussionen im Forum konnte ein timing Problem ausgemacht werden.
Der Rest war einfach: Die Erkennung der USB-SSD brauchte etwas mehr Zeit. Ein Eintrag in der /etc/rc gibt dem System jetzt 5 Sekunden mehr Zeit zur Erkennung der SSD.
So habe ich ein sleep 5 in die /etc/rc geschrieben, und zwar vor die Zeile:
# If bootblocks failed to give us random, try to cause some churn
(dmesg; sysctl hw{uuid,serialno,sensors} ) > /dev/random 2>&1
Je nach System und Version befindet sich die gesuchte Zeile bei ungefähr 400.
Seitdem booten die Einplatinenrechner einwandfrei durch. Bei einem Versionsupgrade oder sysupgrade kann es aber eine neue /etc/rc geben, sodass der Eintrag neu geschrieben werden muss. Muss man halt dran denken.
NetBSD kann, wie auch OpenBSD und FreeBSD recht einfach auf eine höhere Version gebracht werden. Das Werzeug dazu heisst sysupgrade. Es wird nicht automatisch installiert, sondern muss per pkgin manuell installiert werden (# pkgin in sysupgrade).
Soll beispielsweise ein NetBSD 9.0 auf 9.3 hochgezogen werden, dann sähe der Aufruf von sysupgrade so aus:
# sysupgrade auto https://cdn.NetBSD.org/pub/NetBSD/NetBSD-9.3/evbarm-aarch64
In obigem Beispiel wird ein NetBSD für einen RaspBerryPi mit arm64 Prozessor hochgezogen. Das war's aber auch schon, und die Prozedur läuft automatisch durch.
Soll auf ein höheres Major Release hochgezogen werden, also beispielsweise von 9.3 auf 10.0, muss ein wenig manueller Aufwand getrieben werden.
Das könnte dann für ein amd64-System so aussehen:
# sysupgrade fetch https://cdn.NetBSD.org/pub/NetBSD/NetBSD-10.0_RC4/amd64
# sysupgrade kernel
# sysupgrade modules
# reboot
# sysupgrade sets
# sysupgrade etcupdate
# sysupgrade postinstall
# sysupgrade clean
# reboot
Fertig. Ein uname -a nach dem letzten Reboot zeigt nun ein NetBSD 10.0 an.
Wenn unter NetBSD der wpa_supplicant nicht automatisch startet, obwohl in der /etc/rc.conf der Eintrag "wpa_supplicant=YES" steht, dann liegt das wahrscheinlich daran, dass das usr-Verzeichnis auf einem anderen Datenträger liegt und gemountet ist.
Das liegt daran, dass das /usr-Dateisystem mittels mountcritremote gemountet wird (alte NetBSD-Tradition).
Zur Lösung des Problems gibt es mehrere Möglichkeiten:
Das /usr-Dateisystem muss mittels mountcritlocal gemountet werden. Das wird durch den Eintrag von "critical_filesystems_local="/usr /var" in der /etc/rc.conf erreicht.
Die ausführbare Datei /usr/sbin/wpa_supplicant wird nach /sbin verschoben.
Der wpa_supplicant wird nicht mehr per Eintrag in der /etc/rc.conf aufgerufen, sondern in der /etc/rc.local.
Aus gegebenem Anlass gibt es heute eine Beschreibung, wie die Tastatur eines alten Asus K53U Laptop gewechselt wird. Ist eigentlich nicht schwierig.
Die beiden Befestigungsschrauben im Speicherschacht werden in vielen Youtube-Beschreibungen nicht genannt, und wer die vergisst, bekommt die Tastatur natuerlich nicht heraus.
Jetzt die neue Tastatur so in Position bringen, dass das Flachbandkabel in den Stecker eingefaedelt werden kann, danach die Sicherungshebel des Steckers wieder einklappen.
Dann die Tastatur unten wieder einsetzen und oben vorsichtig unter die oberen Klammern einrasten lassen.
Der Asus K53U ist zwar ein altes Stueck IT-Geschichte, aber mit einem schmalen OS wie OpenBSD oder NetBSD noch gut zu gebrauchen. Und eine Ersatztastatur ist zwischen 10 und 20 Euro zu bekommen. Das lohnt also noch.
Auf einem meiner Rechner mit ASUS F2A85M-Board hatte ich sporadische Probleme, die nur unter OpenBSD auftraten. Es gab völlig unregelmäßig Hänger in allen möglichen Anwendungen, besonders aber in Firefox und Google Chrome. Dabei hat die Anwendung nicht mehr reagiert und die HD-LED des Rechners leuchtete dabei dauerhaft. Die Hänger lagen zwischen ca. 3 und 30 Sekunden. Danach ging alles normal weiter.
Ein zweites Problem waren ebenso sporadische Abstürze von Firefox: Zack, einfach weg. Dabei gab es keine Einträge in irgendwelchen Logs.
Mein erster Verdacht war ein Hardware-Problem. Ein neues Board, eine neue SSD und ein Netzteil lagen schon bereit. Durch eine Diskussion in bsdforen.de kam ich aber auf eine andere Spur. Tests mit glxgears -info und WebGL Samples liessen mich mich in Richtung Grafik weiter suchen.
Die Lösung: Etwa vor 2 Jahren hat OpenBSD die device nodes für die Grafik geändert von /dev/drm0 auf /dev/dri/card0. Alle dafür releveanten Änderungen hätten bei einem Upgrade angepasst werden sollen - und das hat wohl nicht immer korrekt funktioniert. Der xenodm beispielsweise hätte die Dateiattribute von /dev/dri/card0 auf den Benutzer von Xorg beim Start ändern müssen. Hat er aber nicht.
Bei mir hat heut nacht ein einfaches sysmerge gereicht, das in Ordnung zu bringen. Seitdem sieht die Ausgabe von glxgears - info auch vernünftig aus:
[berni@tc58 ~] $ glxgears -info
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER = AMD ARUBA (DRM 2.50.0 / 7.2, LLVM 13.0.0)
GL_VERSION = 3.1 Mesa 22.1.7
GL_VENDOR = X.Org
VisualID 1288, 0x508
306 frames in 5.0 seconds = 61.149 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 59.998 FPS
Zur einfachen Überprüfung reicht ein Blick auf /dev/dri/card0: Nach dem Start von Xorg via xenodm muss der Eigentümer dieser Datei der entsprechende Benutzer sein, also der, der Xorg gestartet hat. Wenn nach wie vor root der Eigentümer ist, ist was faul. Dann mal ein sysmerge laufen lassen.