Unix

...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.

locales unter DragonflyBSD

Ja, mit locales habe ich unter fast allen BSD so meine Probleme. Ganz schlimm war es unter DragonflyBSD 6.4.2, wo ich mir nur mit fiesen workarounds helfen konnte.

Das geht sicher eleganter, aber derzeit sieht meine Lösung so aus:

1) In der /etc/login.conf habe ich die Sektion default:\ um das hier erweitert:

:charset=UTF-8:\
:lang=de_DE.UTF-8:

2) In der ~/.profile der User wird dies hier zusätzlich eingetragen:

export LANG=de_DE.UTF-8
export MM_CHARSET=UTF-8
kbdmap -l de
export LANG=de_DE.ISO8859-15

Der UTF-8 Eintrag in der .profile (oder .cshrc) ist eigentlich ummötig, weil das ja bereits in der /etc/login.conf steht. Also nur zur Sicherheit, schaden kanns nicht.

Das Hauptproblem war, dass bei der Installation von DragonflyBSD zwar mittels kbdmap eine korrekte keymap in der /etc/rc.conf eingetragen wurde, die aber beim Einloggen offensichtlich nicht berücksichtigt wurde.

Wenn jetzt kbdmap -l de aufgerufen wurde, erschien das Auswahlmenü für die keymap - sehr lästig und unzumutbar. Wurde aber LANG auf Unicode gesetzt (also LANG=de_DE.UTF-8 ), erschien das Auswahlfenster nicht und die keymap wurde ordnungsgemäß gesetzt. Allerdings gabs mit UTF-8 die Umlaute nur bei jedem zweiten Tastendruck. Das wurde mit dem ISO8859-15 Eintrag behoben, Alternativ reicht auch ein Aufruf von set -o vi in der .profile.

Irgendwie schräg, und irgendwann finde ich höchstwahrscheinlich eine bessere Lösung. Aber erstmal habe ich jetzt funktionierende locales. Es gibt also alle Umlaute und Sonderzeichen der deutschen Tastatur.

NetBSD: gop Einstellung in /boot.cfg

Unter NetBSD habe ich es ein paar mal erlebt, dass nach der Installation des Betriebssystems die Grafik sowohl auf der Console als auch unter Xorg sehr schlecht war: Auf der Console waren die Schriftzeichen viel zu gross und unter Xorg war die Auflösung miserabel und weit unterhalb von Full HD, also 1920x1080.

Meine Lösung war dann immer, die gop-Einstellung in der /boot.cfg zu ändern. Der Parameter gop ändert dabei Einstellungen im Graphics Output Protocol (GOP).

Um den richtigen Wert für gop zu ermitteln, wird NetBSD gebootet und dabei im Bootmenü die Auswahl Drop to boot prompt gewählt. Am Boot Prompt dann zunächst die möglichen Parameter für gop abfragen: gop list zeigt nun die Möglichkeiten an. Für Full HD war es bei mir zuletzt der Eintrag 6, der 1920x1080 anbot. Das kann aber auch eine andere Zahl sein, abhängig von der verbauten Grafikkarte.

Mit gop set 6 wird dieser Parameter übergeben und dann mit boot frisch gebootet. Jetzt kann im realen System überprüft werden, ob die Einstellungen auf der Console und unter Xorg OK sind.

Um diese Einstellung dauerhaft zu machen, wird dann die Datei /boot.cfg geändert. Dazu muss ein Menü-Eintrag in /boot.cfg entweder geändert oder ein neuer Menüpunkt erstellt werden. Ich habe den Standard-Eintrag angepasst, sodass NetBSD einfach durchstarten kann und nicht jedesmal der neue Menüpunkt explizit eingegeben werden muss. Meine /boot.cfg sieht dann so aus:

menu=Boot normally:gop 6;rndseed /var/db/entropy-file;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Drop to boot prompt:prompt
default=1
timeout=5
clear=1

Wie unschwer zu erkennen ist, hat jetzt der erste Eintrag (Boot normally) den Eintrag gop 6 dazu bekommen. Jetzt hat das System überall eine vernünftige Auflösung.

Streifen im kitty Terminal

Irgendwann und eigentlich unerwartet geschah es unter NetBSD, dass das Terminalprogramm Kitty über die gesamte Fläche Querstreifen hatte. Diese gingen mittig durch die Buchstaben und Zahlen im Terminal. Das trat auf unter NetBSD 10.1 und auch 11.0-Beta und das sowohl auf amd64 als auch auf arm64-Rechnern.

Es gab viele Hinweise im Netz, die ich durch probiert habe, aber nichts davon konnte die Streifen beseitigen. Das ganze sah dann so aus:

Kitty mit Streifen unter NetBSD:

Erst mit Hilfe der KI von DuckDuckGo konnte ich das Problem beseitigen. Die Lösung war dann ein Eintrag in der ~/.config/kitty/kitty.conf:

modify_font strikethrough_position 10px

An der Wert von 10px musste ich mich, angefangen mit 1, langsam herantasten. Damit ist Kitty, mittlerweile mein Lieblings-Terminal, wieder streifenfrei. Schön!

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.

Armbian: Signatur abgelaufen

Armbian (auf einem BananaPi M5) bringt bei dem Aufruf "apt update" folgende Warnung:

https://apt.armbian.com/dists/trixie/InRelease: Policy will reject signature within a year, see --audit for details

Erstmal nix Schlimmes, aber nervig und ich sehe die Probleme schon heraufziehen.

Geholfen hat dann, den Armbian-key aus dem Repository neu zu installieren. Das erfolgt so:

wget https://apt.armbian.com/armbian.key

gpg --dearmor < armbian.key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null

Und noch ganz nebenbei: So ein BananaPi M5 eignet sich ganz hervorragend, um darauf ein Pi-hole laufen zu lassen.

Ein gutes Betriebssystem für Maschinen mit ARM-Prozessor: Armbian

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.

Webseiten mit pelican

Kleine Webseiten erstelle ich gern mit Pelican, einem statischen Seiten-Generator. Geht nice & easy und entsprechend schnell. Der Generator ist in Python geschrieben und damit extrem portabel. Tatsächlich gibt es ihn für alle Betriebssysteme, mit denen ich arbeite.

Häufiger muss ich mit einem laufenden Projekt auf einen anderen Computer umziehen. Kein Problem: Einfach das Arbeitsverzichnis herüber kopieren und auf der neuen Maschine pelican installieren.

Und dann wundere ich mich beinahe jedes mal wieder, das der Generator rummeckert und nichts erzeugt. Dann habe ich wieder mal vergessen, eine winzige Installation vorzunehmen.

Richtig ist es also, wie folgt vorzugehen:

1. Arbeitsverzeichnis rüber kopieren, wie auch immer.
2. pelican entsprechend dem jeweiligen OS installieren, z.B pkg_add pelican
3. Zusätzlich pip installieren, heisst meiste py-pip oder py3-pip oder ähnlich.
4. Einmalige Installation mit python -m pip install "pelican"

Und schon läuft der Generator einwandfrei durch. Wird auch mit Markdown gearbeitet, lautet der Aufruf:

python -m pip install "pelican[markdown]"