Hey everyone! As some of you may know, the upgrade of systemd under Solus has been long desired / requested by our users, and there's some pretty good reasons why.
- Newer features for EFI-based systems (so we can eventually drop clr-boot-manager)
- Newer features in the DHCPv4 and DHCPv6 servers
- Improved security on 64-bit systems to reduce PID collisions.
- Newer features in systemd-resolved for DNS-over-TLS
- Cloudflare DNS is now used as a fallback secondary to Google.
- Bunch of new features for sockets, units, and timers.
Why didn't it happen?
Our systemd upgrade has historically been blocked by an upgrade of OpenSSL. While it obviously isn't impossible to upgrade our OpenSSL and we've done it in the past, the upgrade path is more complex than your average package.
The reason for this is pretty simple and it comes down to a bit of a catch-22: Updating OpenSSL involves also keeping the existing version around, both in the same upgrade, so shipping both at the same time and in the same package, to ensure no libs are removed and ABIs aren't pulled out from underneath python's feet. This has to be done to ensure the package manager (eopkg) continues to function, so we can perform the necessary package transactions to get any new packages to build in the first place.
Basically, updating OpenSSL involves shipping the old and new versions until rebuilds are performed, otherwise we break the package manager. Break the package manager, break package building and obviously users systems. Not fun and a royal pain to get it right. We always strive to provide a flawless upgrade path no matter what the package is, so even having users install some separate package to get certain aspects of their system working, or modifying a file, is absolutely a no-go.
What has changed?
Now, the DNS-over-TLS was one of a few features that primarily used OpenSSL, however we ironically had too new of a GnuTLS to actually take advantage of the support in resolved. In v244, that issue was fixed, but given shifting priorities and the holidays, it was only until recently I was able to re-assess it.
So now, I've moved our systemd to no longer require OpenSSL, but instead use GnuTLS. This unblocks our systemd upgrade and it is one less thing I need to stress about when I upgrade our OpenSSL (slated for between 4.1 and 4.2).
Testing
If you're on the unstable repository already, I urge you to test the new systemd and the upgrade path (basically just sudo eopkg up or checking everything in the Software Center). If you don't know how to test it, or what to test, I'd suggest:
- Booting to your DE of your choice is a pretty good start.
- Testing networking (wired or wireless). We don't leverage systemd-networkd, but we do leverage systemd-resolved, so I would test DNS resolution and validating that any of your own custom DNS server settings (if any) still function. For example, I fully expect my DNS to resolve to my home server running dnsmasq, if it fails to indicate that in my network settings in GNOME Control Center then I know there's an issue.
- Testing your systemd timers and sockets, if any. If you use any services like nginx or Docker, double check that they work.
- Suspend, hibernate, rebooting, shutdown.
- Other bits and bobs. Lemme know if something breaks.
Please note that this upgrade can be quite risky. If you're on stable repo, seriously I'm not providing info for you to use the unstable repo and potentially bork your machine. If you're on unstable and you're willing to risk having to chroot into your machine from a Live ISO (have one ready) to revert the package updates if your system fails to boot, then this is the update for you to test. Otherwise don't do it either. Regardless, read the testing notes please.
Testing Notes
- If you see usysconf trigger errors for sysusers and tmpfiles during installation of packages prior to systemd, they should be safe to ignore assuming you actually perform a full system upgrade. Just reboot and run
sudo usysconf run -f from the Terminal just to confirm that "Reloading systemd configuration" and "Re-executing systemd" work.
- Please perform a full shutdown of your system using the power button on your laptop or desktop (as in, press and hold it until it shuts down). Otherwise you'll be prompted by polkit for authentication on the reboot.target, and it'll fail with access denied. Basically you're ripping systemd out from underneath itself, this is normal and you shouldn't see it on any future attempts after the forced shutdown. At least, I didn't.
