now with blue screen of death
Four months after the previous release, systemd 255 is introduced next version. Among the main innovations and notable changes, it is worth highlighting the systemd-vmspawn utility for launching virtual machines, support for exporting drives via NVMe-TCP, the pam_systemd_loadkey.so authentication module and, of course, systemd-bsod for full-screen display of error messages. We will pay special attention to the last component. Well, all the details about the release are under the cut.
What’s new?
As for systemd, an alternative to the classic init subsystem, it was originally developed by Lennart Poettering and Kay Sievers. The project started in 2010, and systemd became the default component of CentOS, Debian, Fedora, openSUSE, Red Hat Enterprise Linux, SUSE Linux Enterprise Server.
The volume of material will not allow us to talk about all the innovations, but we will touch on the most important ones – among them there are very interesting ones:
For example, added component “systemd-storagetm”, which allows you to automatically export all local block devices using the NVMe-TCP (NVMe over TCP) driver. Thus, it opens up the ability to access NVMe drives over the network (NVM Express over Fabrics) using the TCP protocol. The “storage-target-mode.target” component is responsible for access, which can be enabled at the download stage. To do this, you need to specify “rd.systemd.unit=storage-target-mode.target” on the kernel command line.
A new utility has appeared for analyzing and predicting the states of the TPM2 PCR (Platform Configuration Register) registers and generating access rules stored in the TPM2 NV index. The utility is called “systemd-pcrlock”. As for access, we are talking about allowing access to TPM2 objects, such as disk encryption keys, only from digitally signed components launched at the verified boot stage.
Units now have new properties including MemoryPeak, MemorySwapPeak, MemorySwapCurrent and MemoryZSwapCurrent. These correspond to the properties memory.peak, memory.swap.peak, memory.swap.current and memory.zswap.current available through cgroup v2. Information about these properties is included in the output of systemctl status.
In addition, a new utility “systemd-vmspawn” has been added. This is actually an analogue of systemd-nspawn for launching an operating system image in a virtual machine (the “systemd-nspawn” utility is intended for launching containers, and “systemd-vmspawn” provides a similar interface for virtual machines).
It is also worth mentioning the change in the way services are launched, switched to using posix_spawn with the CLONE_VM and CLONE_VFORK options to start the process, and the use of a separate executable file “systemd-executor” to configure the launched process. Previously, processes were branched with the fork function, copying the memory of the control process in copy-on-write mode and performing the necessary settings (mounting namespaces and setting CGroup).
An important change is the end of support for separate directory hierarchies (when /usr is mounted separately from the root, or the directories /bin and /usr/bin, /lib and /usr/lib are separated). In the future, it has also been decided to discontinue support for cgroups v1, System V service scripts, and SystemdOptions EFI variables.
The SuspendMode, HybridSleepMode, HibernateStat and HybridSleepState parameters in the ” section were also declared obsolete[Sleep]” file “systemd-sleep.conf”. These parameters are now ignored and can only take default values.
But units now have the SurviveFinalKillSignal option, which allows you to ignore the final SIGTERM/SIGKILL signal issued during shutdown.
New options have appeared in the “systemd-repart” utility: “–copy-from” to obtain partition descriptions from the specified file system image, “–copy-source” to specify the base directory for the CopyFiles parameter, “–make-ddi=confext “, “–make-ddi=sysext” and “–make-ddi=portable” to generate different DDI types, “–tpm2-device-key” to bind the disk to a specific TPM2 public key.
As for the systemd-analyze, systemd-tmpfiles, systemd-sysusers, systemd-sysctl and systemd-binfmt utilities, they now have a new option “–tldr” to display only the actual configuration parameters without spaces or comments.
Support for the LoongArch64 architecture has been added to the seccomp subsystem. Allowed to use seccomp to filter system calls in services not running under the root user without enabling the NoNewPrivileges=yes setting.
Well, now – about systemd-bsod and the “blue screen of death”
Usually, when we talk about BSOD, the same screen from Windows immediately appears before our eyes. Of course, it was not always blue; for the first time in a more or less modern form it was back in Windows NT 3.1.
With each new version of Microsoft’s operating system, the appearance of this screen has changed. So, in versions 9x the error message was very short. Everything changed with Windows XP, where the developers added a little more data about the problem they found.
Starting with the “eight”, a sad emoticon appears on the BSOD, and technical information has not disappeared anywhere. An interesting point: in Windows 11, the Blue Screen of Death was made black, but after the majority of users expressed dissatisfaction, the blue color was returned. Perhaps the reason was not the users, but there were really a lot of people outraged by the color change.
Well, now Linux users will be able to see something similar to BSOD. This pleasure is provided by the systemd-bsod component. It displays error messages from the LOG_EMERG log in full screen mode.
The text is white so it is easy to read against the light blue background. Following the example of BSOD from later versions of Windows, systemd-bsod also displays a QR code on the screen, which is located in the lower right corner. The code can be read using a smartphone, receiving more or less detailed information about the error.
The developers are confident that this innovation will be useful in identifying and solving problems that are associated with the Linux kernel and hardware. It is a much more visual tool for monitoring and troubleshooting difficulties that may arise during the OS boot process.
