31 Mar 2010 – Lennart Poettering. My Stuff. I’ll Break Your Audio Something like a web log, mostly about Free Software and photography …
Now Lennart’s aspirations have grown and with things like systemd, he’s now breaking all our systems completely, so much more than just audio (**)
I’m thinking it may be useful to have a script that checks out a running system for practices, that may cause upgrade troubles, like having a seperate /usr, and some advice how to Lennartify the running system.
So we can be nagged by Lennart, before upgrading rather than afterwards with a broken system, I am wondering about a virtual Lennart package to run
Anyone got any up to date pointers on documentation of requirements or suggestions for what to include?
I would guess, checking out /boot as well as / & /usr, would be worthwhile. There’s probably quite a lot of ppl with things that work, but more by luck than judgement.
Can use some of the advice for Tumbleweed to.
(**) For record, it’s actually desktop developers hooking /usr stuff into udev rules that are real culprits… & Pulse Audio seems OK to install these days to!
My /usr has been seperate, as is /boot and /var, except on test installs and I like ro filesystems with funky options like noacl.
I’m not sure if a separate application is the proper approach. What about just booting with systemd and seeing if things break. Of course, for the process to be reversible, you cannot just install systemd. But it’s possible to leverage the boot-qemu-on-harddrive-in-snapshot-mode trick, see e.g. freedesktop.org - Software/systemd/VirtualizedTesting.
In your case, you’d boot the throw-away machine, install systemd inside, and see what happens
It seems that one of the big features of systemd (vs alternatives like Debian Upstart) is full support for legacy (SysVinit, udev, etc) so that any upgrades can typically be done gradually and <by choice>. Although systemd is now the master of the running system, individual “Unit” services kick off legacy sub-systems so that they continue to function as reliable alternatives to and until they can be replaced as systemd Units themselves.
For this reason, I believe that it has become (if not long already) critical to upgrade using a recommended upgrade path from distro version to version to ensure upgrade scripts are run to upgrade numerous parts of the system properly… There can no longer be any jumps that skip a version. And, it looks like migration to systemd will take years just for existing goals (not even accounting for expanding into new areas like audio subsystems) so it’ll be this way for the forseeable future.
BTW - If systemd can really flatten the many layers of today’s Linux audio systems (ALSA, Phoronix) and simply an architecture that is evolving towards complexity, that sounds great to me.
So, bottom line is that IMO some systemd related upgrade test might be interesting and maybe even useful for faster upgrades but likely unnecessary for people who closely follow <only> recommended upgrade paths (and a periodic system re-build from scratch probably wouldn’t hurt, either).
(**)