2025.04.30
It’s been almost a year and a half now since I first installed OpenBSD 7.3 on the Lenovo T490 and decided to stop distro hopping. This was helped in part by the fact that the other BSDs were not really working properly on this machine (sadface), and despite the significant paradigm shift it led to good things. The short version? I love BSD, but like anything else it’s not without some problems.
I’ve followed OpenBSD up to the 7.5 release without much hassle, but after upgrading to 7.6 I couldn’t get past the xenodm login screen. It would hang for a second and reset, asking for my login credentials again. This was not because of a mis-typed username or password either. Disappointed, I went back to 7.5 and stayed there until the 7.7 release came out. I then upgraded to 7.6 and then straight to 7.7, only to find that it suffers from the same issue! At this point I logged in through the console and started checking log files. Here’s what I found in /var/log/xenodm.log:
X connection to :0 broken (explicit kill or server shutdown)
Interesting. I have no idea what it means, and what’s even more puzzling is that I can’t find even a single instance of anyone else having this problem on OpenBSD! Brilliant. I did prepare a full disk image of the 7.5 installation, so restoring the system would just require about half an hour of waiting for dd(1) to do its thing, but then it won’t be long before 7.5 is EOL.
I made copies of the relevent log files in the hopes of preparing a bug report and proceeded to install FreeBSD 14.2, but there was (yet another) problem… By the time everything was installed and configured the way I wanted, I found that I was missing th .xsession-errors file for the bug report. Oh sure, I’ve got Xorg.0.log, xenodem.log and a copy of dmesg, but how can I hope to file a proper bug report if I’m missing what could be useful (even critical) information? I don’t even remember what was in that file, but it was the first one I checked, and I know the contents differed from the others so it might be wise to include it.
So now I have to make yet another full disk image of the new system before restoring OpenBSD 7.5 and repeating the 7.6/7.7 upgrade failure just to get one file, and because I’m just that stubborn and persistant, and because I do believe in OpenBSD, I think it’s worth my time. Thankfully the upgrade works fine on the server, so now I have two different BSDs to manage. This is not my preferred setup since I’d like to just focus on ONE operating system, but it could be worse. Oh so much worse! I could be locked up in the Apple prison egosystem, or fighting with Linux, or even (god forbid) suffering the nightmare that is M1CR0$0FT W1N-Dohz -screams in horror-.
But I do want to replace the server with something more sensible, and if that something happens to run FreeBSD then I’d have access to ZFS, which could greatly simplify backup and restore. Oh, and let’s not forget the much larger number of packages and ports, and Jails, and all those knobs to turn in /boot and /etc conf files. The use of sane command names like ‘pkg install’ instead of ‘pkg_add’[1], the Handbook… Oh how I’ve missed FreeBSD! But then I’d also miss things like pledge and unveil, and all the other security measures that make OpenBSD secure by default (unless you happen to do something stupid).
It seems now I’ve got another series to write: FreeBSD on the Lenovo T490. This should be interesting.
[1] I think there’s a package that solves this weird quirk by wrapping each pkg_* command in a sane format like the one used by FreeBSD’s pkg(8). I don’t remember the name of it, but it might be mentioned in the FAQ.