Unix

mkdocs unter OpenBSD

Bisher habe ich meine Blogs unter Hugo und Pelican geschrieben und bin mit beiden statischen Generatoren absolut zufrieden. Dennoch schaue ich mich ab und zu nach Alternativen um und dabei bin ich auf mkdocs gestossen. Erschien mir interessant zu sein, auch weil es für reine Dokumenation gut einsetzbar ist.

Das mkdocs Framework ist in Python geschrieben, was mir schon mal sehr sympathisch ist. Bislang hab ich es auf mehreren Betriebssystem installiert: OpenBSD, NetBSD, DragonFly BSD und MidnightBSD. Läuft auf all diesen Platformen einwandfrei,

Im Folgenden beschreibe ich in aller Kürze die einzelnen Schritte für die Installation von mkdocs:

Zuerst als root Python und py-pip installieren. Ich habe Python3.12 dafür genommen.
# pkg_add python3.12 py3-pip

Dann ein Projekt-Verzeichnis erstellt und dorthin gewechselt:
mkdir ~/work/projekt1
cd ~/work/projekt1

In diesem neuen Verzeichnis wird eine virtuelle Umgebung in einem Verzeichnis namens venv eingerichtet. Der Name des Verzeichnisses ist natürlich frei wählbar:
python3 -m venv venv

Nun kann diese virtuelle Umgebung aktiviert werden:
source venv/bin/activate

Ab jetzt zeigt ein (venv) vor dem normalen Prompt an, dass die virtuelle Umgebung aktiv ist. Der Prompt könnte dann z.B. so aussehen:

(venv) $berni@raspi56 ~/work/projekt1 $_

Zum Schluss muss natürlich noch mkdocs und material installiert werden:

pip install --upgrade pip
pip install mkdocs mkdocs-material

Beachte, dass die Installation innerhalb der virtuellen Umgebung erfolgen muss. Klappt aber auch sonst nicht.

Jetzt kann mit der eigentlichen Arbeit am Blog oder der Dokumentatio begonnen werden.
mkdocs new projektname erstellt ein Skelett für ein neues Projekt. Bei mir war es meist so, dass ich vorhandene Pelican-Projekte übernommen habe und die Posts, Pages und Images ins mkdocs-Verzeichnis kopiert habe. Anschliessen dann die mkdocs.yml angepasst.

...too big for the bo

Auf manchen älteren ASUS Mainboards der der Baureihe F2A85M... mit AMD A8 oder A10 Prozessoren hatte ich unter OpenBSD häufig die kryptische Fehlermeldung vbo resource seems to be too big for the bo. Dies trat auf beim Starten von xorg und auch danach beim Aufruf verschiedener Programme.

Spürbare Effekte hatten diese Meldungen nicht, aber sie müllten auch gern ganze Bildschirme voll. Irgendwann hatte ich die Nase voll und begann, die Ursache zu suchen - mit Hilfe der KI. Unsere Zusammenarbeit war dann letztendlich erfolgreich und ich konnte die Meldungen durch eine Konfigurationsdatei unter /etc/X11/xorg.conf.d abstellen.

Der Dateiname ist quasi beliebig, beispielsweise kann er 00-radeon-to-big.conf lauten. Wichtig ist der Inhalt und der sieht bei mir so aus:

    Identifier "Card0"
        Driver     "radeon"
        Option     "AccelMethod" "EXA"
        Option     "ColorTiling" "on"
        Option     "ColorTiling2D" "on"
    EndSection

Und seitdem ist Ruhe. Aber Achtung: Für diese Fehlermeldung kommen auch andere Ursachen in Frage, aber bei der alten Radeon-Grafik hats geholfen.

OpenBSD und RaspberryPI 5 GPIO uart

Es gibt leider Dinge, die ich mir ganz schlecht merken kann. Dazu gehört auch das Wissen um die Funktionen der GPIO Pins. Nur aus diesem Grund lege ich hier ein Foto der GPIO ab. Wenn ich mir's oft genug anschaue, weiss ich irgendwann auswendig, welche Pins für die uarts sind.

Schönes Fotos mit allen GPIO Pins.

Und noch eine Hilfe: Die Bezeichnung und farbliche Zuordnung der drei Leitungen TXD, RXD und GND des Adapters Seriell-USB.

Und so muss ich adaptieren, wenn ich ich den internen kleinen Stecker für den Debug uart des RaspberryPi 5 anschliessen will. Brauch ich aber nur, wenn nicht der spezielle Probe uart benutzt wird, sondern einer meiner Standard-Adapter.

U-Boot Gefrickel

Das U-Boot, also der Bootloader für den RaspBerryPi 5 mit OpenBSD, ist ja eine feine Sache und funktioniert auch. Allerdings muss für den Einsatz von OpenBSD ein U-Boot-Parameter geändert werden, was nur mit einer seriellen Verbindung zwischen dem RaspberryPi und einem zweiten Rechner möglich ist.

Wenn ohnehin gerade frisch installiert wird, ist das natürlich kein Problem: Der Raspi ist dann ohnehin geöffnet und der Stecker für den seriellen Anschluss einigermassen zugänglich.

Ich habe bisher 3 Raspi 5 auf diese Art und Weise installiert, kein Problem. Trotzdem habe ich überlegt, wie ich die serielle Verbindung umgehen kann. Ich habs tatsächlich hinbekommen, aber es war ein ziemliches Gefrickel - allerdings Software-Gefrickel. Das Hardware-Gefrickel konnte ich damit umgehen.

Was habe ich gemacht? Hier im Stenogram-Stil die Schritte:

• Mit dd if=/dev/sd1c of=obsd-rpi5.img bs=1m die SD-Karte eines laufenden OpenBSD in eine Datei geschrieben.

• Mit dd if=obsd-rpi5.img of=/dev/sd2c bs=1m das Image auf eine neue SD-Karte geschrieben.

• Damit habe ich jetzt eine bootfähige SD-Karte mit einem bereits modifizierten U-Boot. Die entsprechende Datei auf der Karte ist die uboot.env.

• Die SD-Karte wurde nun an einem anderen Rechner gemountet, idealerweise einem mit OpenBSD. Dort gibt es unter /etc eine Datei boot.conf. Die habe ich erstellt und dort eingetragen, dass ins HDMI, also in einen Bildschirm gebootet wird. Die Datei enthält bis jetzt nur die Zeile set tty fb0. Dies wird jetzt erweitert durch boot bsd.rd, natürlich in einer neuen Zeile.

• Nun kommt die neue SD-Karte in den Slot des RaspberryPi 5 und wird gebootet. Der Rechner startet, das U-Boot lädt OpenBSD, das geht sofort auf den Bildschirm und landet dann im Installations-Menü von OpenBSD. Je nach Bedarf kann jetzt ein Update oder eine Neuinstallation gestartet werden. Ich nutze die SD-Karte fast immer nur als Root-Partition und installiere den Rest des Systems auf einer NVME, eine der grössten Errungenschaften des RPI5.

• Wichtig! Nach abgeschlossener Installaion nicht sofort neu Booten, sondern eine Shell aurfufen. Das neu installierte System ist noch unter /mnt gemountet, also ins Verzeichnis /mnt/etc wechseln. Jetzt muss der Eintrag boot bsd.rd aus der boot.conf entfernt werden. Am einfachsten durch Überschreiben mit echo "set tty fb0" > boot.conf

• Nun mit exit zurück ins Installations-Menü und von dort aus neu gebootet. Der Rechner wird jetzt mit dem neuen OpenBSD starten.

• Die Geschichte ist aber damit noch nicht fertig. Das System hat jetzt natürlich alle Einstellungen des Muttersystems, beispielsweise auch dessen MAC-Adresse, den hostname und was sonst noch individuell konfiguriert wurde. Das muss alles angepasst werden, eventuell brauchts auch eine neue MAC-Adresse. Das ist aber alles nicht wirklich schwierig, macht jedoch ein wenig Arbeit.

Erspart habe ich mir aber eventuell das Ausbauen der Raspi-Platine aus dem Gehäuse, vielleicht die Anschaffung eines debug uart Kabels, den Aus- und Wiedereinbau der NVME-Platine und und und. Die Zugänglichkeit des debug uart ist beim Raspi leider nicht sehr gut gelöst.

U-Boot startet OpenBSD nicht

Nachdem es gelungen war, OpenBSD auf dem RaspberryPi 5 zu installieren, trat ein weiteres Problem auf: Das U-Boot.

Während ich bis zum RaspberryPi 4 OpenBSD über die EDK-Firmware booten konnte, funktioniert das beim RaspberryPi 5 nicht damit. Statt dessen werden die Systeme mit dem U-Boot gestartet, einem universellen Bootloader für Arm64-Systeme. Das U-Boot richtet beim Start die Hardware-Komponenten ein und startet danach das Betriebssystem.

Nun trat bei der Kombination Raspi5/OpenBSD ein merkwürdiges Verhalten auf: Die Installation wurde über die serielle Schnittstelle durchgeführt, anschliessend und für den Alltagsbetrieb hat die Datei /etc/boot.conf mit dem Eintrag set tty fb0 die Ausgabe auf HDMI, also den Monitor, gesetzt.

Und nun passierte folgendes: War der Raspberry 5 noch seriell mit dem Installationsrechner verbunden und war diese Verbindung noch aktiv, klappte alles wie am Schnürchen: Das U-Boot startete den Raspi, zeigt dabei kurz sein Logo oben rechts auf dem Monitor und startete dann wie gewünscht das System, also OpenBSD.

Bestand diese serielle Verbindung aber nicht mehr, startete zwar das U-Boot, aber das Logo blieb dauerhauft sichtbar und OpenBSD wurde nicht geladen. Dann musste ich die serielle Verbindung wieder herstellen und konnte dann im Terminal-Programm, z.B. cu, sehen, das es nur bis zum U-Boot-Prompt gelaufen war. Jetzt musste boot eingetippt werden, und dann erst wurde OpenBSD gestartet. Das war natürlich Mist.

Die Lösung kam, nicht unerwartet, über die OpenBSD-Arm-Mailing-Liste. Im U-Boot muss die Umgebungsvariable bootdelay auf -2 gesetzt werden. Das erfolgt am U-Boot-Prompt über die serielle Verbindung mit zwei Befehlen:

setenv bootdelay -2

saveenv

Also die Variablesetzen und dann abspeichern. Damit läuft (bisher) jeder Gerätestart sauber bis zum OpenBSD-Prompt durch. Das Leben kann so einfach sein!

Ach ja, eines noch: Beim Raspberry 5 muss die Debug-Schnittstelle benutzt werden, mit der GPIO-Schnittstelle gibts keine Verbindung. Muss man auch wissen.

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.

locale unter Openbsd

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.

OpenBSD: Probleme mit Arm64 Rechnern

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.

Falscher Eigentümer /dev/dri/card0

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.

Openbsd auf BPi-M5

Nachdem meine BPi-M5 mit Arch- bzw. Armtix-Linux ordentlich laufen, will ich mich über die Feiertage bemühen, ein BSD auf die Maschinchen zu kriegen. Anfang des Jahres hatte ja der User @zoidb3rg in den bsdforen.de beschrieben, wie er erfolgreich ein OpenBSD auf einem BPi 1 installiert hat. Hab ich mir alles noch mal gründlich durchgelesen und auch versucht, aber das konnte ja nur schief gehen: Ein BPi1 ist nunmal kein BPi-M5, da passt ja garnix, andere CPU, kann also nicht gehen. Und so war es auch: So sagt der M5 keinen Mucks, kein Bild, kein Ton.

Dann die OpenBSD-Arm mailing list durchgearbeitet. Ein Tipp war, das u-boot vom Odroid C4 zu nehmen. Ging aber auch nicht, vermutlich weil die SoC nicht ganz identisch war: Anfangs hatte der C4 wohl eine amlogic S905X2, während der BPi-M5 eine S905S3 hat. Und es schien tatsächlich so, dass für den BPi-M5 kein u-boot zur Verfügung steht.

Aber dann der entscheidende Hinweis: Ein mainline u-boot, auch den BPi-M5 sollte existieren (Thanks a lot, Mark), den Link gabs dazu. Und dann war alles ganz einfach:

OpenBSD arm64 als install72.img herunterladen, hier gabs das u-boot dazu. Zuerst das OpenBSD image auf eine uSD Karte geschrieben:

# dd if=install72.img of=/dev/sd5c bs=1m

Dann in zwei Schritten das u-boot auf dieselbe SD gebracht:

# dd if=u-boot.bin.sd.bin of=/dev/sd5c bs=512 skip=1 seek=1

# dd if=u-boot.bin.sd.bin of=/dev/sd5c bs=1 count=444

(sd5 natürlich nur bei mir)

Klar, dass die Ausgabe zunächst auf den UART ging, kannte ich ja schon vom Raspberry. Weniger klar war, dass die Ausgabe nicht auf den UART der GPIO geht, sondern auf den debug_uart auf dem Board. Natürlich nicht dokumentiert, so dass ein bisschen Gefrickel nötig war.

Aber OK, jetzt gabs Daten, hab dann das System installiert, was gewohnt einfach war. Das / hab ich auf die interne emmc (16GB) gelegt, alle anderen Partitionen auf eine externe (USB) SSD mit 128 GB.

Nach der Grundinstallation noch set tty fb0 in die /etc/boot.conf geschrieben, damit ab jetzt die Ausgabe auf HDMI geht. Der erste Bootversuch ging dann aber doch schief, weil das u-boot den falschen Datenträger booten wollte. Dabei zeigte sich, dass die interne emmc im laufenden Betrieb als sd0 erkannt wird, beim Booten aber als sd1. Dagegen half ein weiterer Eintrag in der /etc/boot.conf: boot sd1a:/bsd. Damit war die Welt wieder in Ordnung, das System bootet ordentlich und auch schnell, denn die emmc ist deutlich flotter als eine uSD Karte.

Jetzt kann ich in aller Ruhe über den Jahreswechsel sehen, was alles funktioniert. Für meinen angedachten Einsatzfall ist der Banana aber jetzt schon geeignet, wlan und sound brauche ich nicht, werds aber trotzdem checken.

Kleiner Nachtrag: Noch besser läuft die ganze Geschichte, wenn man den Bootloader, also das u-boot, auch auf die emmc schreibt (mit den gleichen beiden dd-Kommandos wie oben) und die µSD ganz entfernt. Dann ist der Bootvorgang noch etwas schneller. Ansonsten läuft das System Banana+OpenBSD einwandfrei und rock solid.

Und so siehts aus: