An orange in an apple orchard
www.theregister.com/2023/03/08/debian_12_apt_2_6/
While I’ve mostly found Debian systems needing a separate repo enabled to pull in device firmware annoying, I’ve also always given them a little respect for sticking to their guns. Crazy as they might be.
Part of me wonders if Sid’s back yard just froze over 😅
After a good while, I’ve finally upgraded my main laptop from Debian Stretch to Buster. Unless your name is OpenBSD, I don’t do zero day upgrades; and it’s been a few months since Buster shipped. Enough for me to feel comfortable that any big, scaries about the new Debian stable would have made it to my ears by now.
It’s long been my policy to upgrade a less important machine before pushing a major upgrade to one I don’t want to wipe and restore from backups.
My guinea pig was a desktop that’s been running Debian stable releases since Squeeze without a serious problem. The only issue I experienced with it on upgrade was that the antique nVidia card requires a very legacy driver version that doesn’t really want to work with the current OS. But aside from that everything was peachy.
My laptop on the otherhand was a fairly painless experience. I only encountered two issues.
One is it looks like consolekit has been ejected in favour of systemd-logind. Frankly, I don’t care. But I also am a weirdo who still likes to run XDM. Because beyond configuring PAM or my X session script, I don’t give a flying floop about the modern login managers–my session still trucks through ~/.xsession and I don’t need fancy stuff in my login screen. A small change to the xfce4 specific part seems to be enough to resolve that, or at least I can still reboot my laptop through the xfce4 menu instead of using sudo.
Second case was for whatever reason, apache2.service wanted to be enabled during the upgrade and was preventing lighttpd.service from starting and running my tweaked configuration. So when I saw my /var/www/html/index.html file about altering an NSA surveillance unit, I knew that was happening. That’s actually why that file exists. If you’re not using my configuration that makes content go to /srv/{hostname}, you get the cheaky file I left myself for being able to tell. Because I know if I stick my shit in /srv/{hostname} rather than /var/www/html, probability of packages mucking with my webroot goes down :P. A simple disable + stop apache2.service and restart lighttpd.service, and bingo.