Soft-reboot in systemd 254 sounds a lot like Windows' Fast Startup

Where does Agent P work again?

Version 254 of systemd marks the 115th release of this ever-growing init system for Linux. Expect to see it in the autumn releases of Ubuntu and Fedora, and in Arch and openSUSE Tumbleweed sooner.

This version brings at least one fairly significant user-facing change that may even be noticed by people who never interact with their init system in any way: faster system reboots.

Some of the other changes will force extra work onto distro maintainers, though. Not all systemd-based distros have merged their /usr hierarchy yet, but this is the last release of systemd that will work with split /usr trees. The usr merge is basically just a fix for some artifacts in the gradual evolution of Unix and Unix-like systems, but over time it grew into dogma.

Under Unix-like OSes, there are a whole bunch of places where programs may be kept: /bin (which once was short for "binaries"), /sbin (nominally "system binaries", those needed to boot and manage the computer), /usr for binaries needed by ordinary users, which also contains /usr/bin/ and /usr/sbin/, and dozens more. The hier(7) manual page has the gory details. There's a whole rationale for this, involving starting computers from extremely small boot media and keeping only the most essential parts on it, and so on, but it's just folklore and post facto justification. The truth is, this started out as cruft that just accreted over the early development of Unix, as recounted in this superb and very readable brief history.

The systemd developers plan to drop support for unmerged /usr hierarchies with the next version. Fedora 17 led the way, and openSUSE Tumblweed made the switch as long ago as 2012. We're not so sure about Leap and SLE, though: there were still special precautions as late as SLE 15 SP4, and we've seen a report that Leap 15.5 hasn't completed it yet.

The Debian team has been working on the merge for years, but as LWN reports, it's not there just yet. This won't happen in a point release, though, and since Debian 12 is only about a month old, we won't see this until Debian 13 "Trixie" in about 2025.

Also, systemd's remaining limited support for System V init scripts – such as the systemd-sysv-generator tool – is going away. Your Reg FOSS vulture is very happy he hasn't had to edit an init script in many years, and does not miss such things even one tiny bit, but all the same it's going to irk some people.

If you're not a system administrator, the new soft-reboot may well be what you notice most. This feature should deliver much faster system reboots so long as you don't need to restart your kernel. It shuts down all userland processes – that is, everything "above" the level of the kernel – mounts a new root filesystem on /run/nextroot/, starts a new systemd instance in there, and then hands over control.

This distinctly reminds us of two features. One is Windows' Fast Startup, which debuted way back in Windows 8. With it enabled, when you shut down a Windows machine, it doesn't fully shut down. Instead it logs you out, shuts down all the user's processors, and then hibernates. When you turn the computer back on, instead of reloading the entire operating system, the Windows kernel wakes from hibernation, then either shows the login screen – or just logs you in and starts up as normal.

The snag with this is that if you dual-boot with Linux, the Windows partition is still technically mounted by the sleeping Windows kernel… so you can't mount it in Linux. Worse still, if you list your NTFS partitions in your /etc/fstab file, systemd will pause and wait for them to become available. Which, of course, they never will, because Windows is hibernated and your machine is currently booted into Linux instead… so your computer fails to boot.

(There's an easy workaround: just disable Windows hibernation. Open an Admin command prompt, and type powercfg /h off. Reboot, and it should never happen again.)

This just shows the sort of hard-to-predict problem that an ostensibly clever feature, such as Windows Fast Startup, can cause. We suspect that the mighty all-knowing systemd developers don't do proletarian things like dual booting. In fact, as Agent P works for Microsoft these days, maybe he just runs WSL 2 instead.

Linux used to have a different but comparable fast-boot feature, which was a side effect of a kernel debugging tool called kexec. Although this did have security implications, it was a handy gadget, even endorsed by IBM. Sadly, it stopped working on Ubuntu years ago.

We can see systemd-soft-reboot causing some of the same issues that rebooting with kexec used to. If you have more than one operating system installed, bypassing the POST process means that you only see your boot menu on a cold start. That means that when you reboot, you can only do it back into the same OS. Also, today, a very common reason for rebooting a Linux computer is to apply kernel updates, but these fast reboots won't help there: your system reloads on top of the self-same kernel. That might not be a problem if you are an enterprise user with live kernel patching enabled, but for the rest of us, it's a new complication to beware of.

There are of course technical ways around this: the system reboot scripts can be made aware of newly installed kernels, and desktop GUIs could be made aware of two different reboot mechanisms. Distro developers are going to find ways to handle this and make efficient use of it… But the flipside is that it means systemd will gradually encroach on even more of your operating system. We suppose that will give the haters something else to shout about. ®

More about


Send us news

Other stories you might like