Unix

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!

Keine VTs unter NetBSD mit xdm

Unter NetBSD setze ich als DisplayManager meist den slim ein. Der wird aber seit längerer Zeit schon nicht mehr gepflegt, und so bin ich auf den xdm umgeschwenkt, der ja ohnehin der bevorzugte DM unter NetBSD ist.

Also einfach den xdm in der /etc/rc.conf mit xdm=YES aktiviert, noch ein nettes Hintergrund-Image in der /etc/X11/xdm/Xsetup_0 geladen und fertig. Dachte ich zumindest.

Der xdm ist auch brav gestartet und hat die .xsession korrekt ausgeführt. Nur konnte ich jetzt nicht mehr mittels Ctrl-Fn auf die VTs, die virtuellen Terminals, umschalten. Die waren weg, und das konnte nur der xdm angerichtet haben.

So war's dann auch, aber mit ein paar wenigen Einstellungen ist das einfach zu reparieren. Das hab ich wie folgt gemacht:

1. In der Datei /etc/X11/xdm/xdm-config die letzte Zeile auskommentiert. Die Zeile sieht dann anschliessend so aus: ! DisplayManager.requestedPort:0

2. In der Datei /etc/X11/xdm/Xservers.ws wird die Zeile mit dem X-Server Aufruf (in meinem Fall war's auch wieder die letzte Zeile) wie folgt geändert: :0 local /usr/X11R7/bin/X vt05 :0

Nach einem Neustart ist die Welt jetzt wieder in Ordnung: Der X-Server läuft auf VT5, also Ctrl-F5, und auf Ctrl-F1 ... Ctrl-F4 habe ich meine Konsolen wieder. So soll es sein.

swapfile unter NetBSD

Die NetBSD-Images für aarch64 (evbarm) enthalten von Hause aus keine swap-Partition. Ehrlich gesagt hab ich die auch noch nie vermisst, und mir ist noch kein RaspBerryPi mit übergelaufenem RAM abgeschmiert. Dennoch gönne ich all meinen Raspis mit NetBSD ein kleines swapfile, ganz besonders denen, die 7/24, also rund um die Uhr laufen und arbeiten müssen, beispielsweise als Kamera-Server oder Web-Server.

Das Erstellen und Aktivieren des Swapfile mache ich so:

1. Erstellen des swapfiles mit dem Namen swapfile im Wurzelverzeichnis des Rechners mit dd if=/dev/zero of=/swapfile bs=10m count=200. Nach wenigen Sekunden ist /swapfile mit der Grösse 2GB erstellt.

2. Die Datei /swapfile erhält die Attribute 600 mittels chmod 0600 /swapfile

3. Das swapfile wird aktiviert mit swapctl -a -p 1 /swapfile

4. Jetzt noch das swapfile in die /etc/fstab eintragen, damit es bei jedem Start automatisch aktiviert wird. Die entsprechende Zeile in /etc/fstab sieht so aus: NAME=swapfile /swapfile none sw,priority=2 0 0

Und das wars's dann auch schon. Jetzt hab ich ein nervenberuhigendes swapfile auf den Raspis.

NetBSD sysupgrade

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.

Netbsd wpa_supplicant startet nicht

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:

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

2. Die ausführbare Datei /usr/sbin/wpa_supplicant wird nach /sbin verschoben.

3. Der wpa_supplicant wird nicht mehr per Eintrag in der /etc/rc.conf aufgerufen, sondern in der /etc/rc.local.