systemd 255 Released With A "Blue Screen of Death" For Linux Systems

[Slartifartblast]

A systemd bunfight, we've not had one of those for a while as I thought everyone had switched to Xorg vs Wayland.

Nice to see some old repeats on TV.

[rrveex]

To use a gaming quote: Everyday Linux strays further and further from Saradomin's light... I mean for pete's sake who needs all of this in an init system. The newer versions of RHEL past 6 and 7 are starting to feel so foreign. RHEL 9 is alien to me nowadays. I'm so glad I upgraded to OpenBSD and FreeBSD. Just wish I didn't have to use RHEL 9 at work. SystemD is not for me!

Artix used to work well for me in the beginning. Lately, package management seems to struggle, mostly because of the same packages on Arch/Artix repos are out of sync. I suppose this is because more Arch packages now depend on systemd and it takes longer for the Artix maintainers to patch them.

I tried Gentoo a couple of times... mixed feelings with it. I find package management much more difficult. Gets easier each time (obviously), I might keep it for good now.

The worse was fucking "webtoolkits" (or whatever they're called on both gtk and qt), hours and hours of building because "version 473.9952.798 > 473.9411.881".

Currently I'm "webtoolkit-free" with stuff like digikam and telegram-desktop running in distrobox. I also masked llvm/clang > some-version in portage.

Anyway, all the trouble with Gentoo seems justified - there's always a valid (and documented!) reason for things being as they are. The opposite seems to be the case with systemd, which throws "features" in at an alarming rate just because "it's cool and maybe someone will like it" (this would be ok for some application, like a music player or such, it's definitely not ok for something the whole system depends on).

I'm running FreeBSD on servers. Can't see the use-case on desktop. You can browse the net and read your mail... The "interesting" things (for me) happen on Linux.

[Mavman]

You wrote a [ Trigger Warning ] for a satire ??? ...

ahahahah you could not resist!!!! ahahahah
yeah, i've set a warning because i do understand it is useful to have a BSOD (and certainly someone would point that out and call me stupid), but still... that is kind of a nightmare on peoples memories from the windows age.
Windows used to present BSOD very often to people's frustration... and it's kind of sad that while windows now very rarely presents a BSOD, we are celebrating that systemd now has the possibility of doing it...

It's just sad that out society has come to this point where you can't throw a bucket of gravel without there being somebody out there that will hypothetically argue -- what if each of those individual gravels is alive and by throwing them you are causing them pain.

Most of us with a brain all know where this non-sense road of pandering to the fragile ends. In utter ruin. /rant --

I won't even comment this part because my frustration with where we're at would lead to a Shakespearean-size rant.... so...

but anyways I found your rant mildly amusing, rant on brother.

thank you!!! I'll try to keep up with the rant ahahahahhaahah at least it keeps frustration under control ahahahahahah

[rrveex]

Can I change the color of the output? I´d like it to be orange or pink?

`systemd-theme` will do that. You'll be also able to synchronize it with your other "devices", like your Windows12 laptop. In case it'll happen without you even configuring it - that's Pluton in the background, convenient, isn't it?

[old486whizz]

So - I can't help but think that this has limited scope (I don't know what would send a LOG_EMERG through to journald/systemd)...

During boot, most "failures" which cause the system to go "unusable" would happen prior to the Kernel handing across to systemd right? In which case how does systemd cause a blue screen?
After that, any boot failures should always drop you to a terminal in order to try and fix things and look at the log output (as it kind of currently does).
After that, on a running system, I can only think of a Kernel panic - which is the kernel actually faulting.... So I guess the same sort of code hook in the kernel could be put in place, as you have with kdump, which could display something (which... it does already doesn't it? ... Last time I saw a kernel panic was on a VM machine that had the fibre storage drop away and we got some panic screens).

So only used for Kernel panics then?
As long as the kernel panic message is presented then I don't see an issue..
Would have preferred a black / green screen myself rather than blue - but mainly because of association with Windows BSOD..

[Retramon]

They nixed them because the error codes were giving users too much unhelpful information causing even more stress to the average user - the vast majority of Windows' users.

However, if you DO have that information and know what you're doing, you can attach a debugger and get the same information as you could in older versions.

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data

Systems programmers where this information is useful should already be aware of this. Everyone else it's just noise.

Or if the whole error detecting and reporting system would be better developed as per default in the core OS, with better and more accessible analysis tools part of the default OS componentry as well, then it would have been a different user experience altogether as advanced users who experience these errors and desperately need a workaround would be able to do so faster and better, not just the developers who happened to have had developer-mode enabled and an attached debugger and were expecting issues.

"Better developed", also in sense that it would do some good error detection without being a performance strain on the system when running normally for maximum performance. People who say this isn't practical have really nothing to compare it to since there's little focus or investment going into these kind of areas on any OS, until someone actually commits to try to make things better and see how far things can be pushed then I'd stay away from making conclusions.

Now, you don't need a debugger or developer mode to get more info from a BSOD's minidump or kernel/full dump, you could already installed developer tools SDK and the bugcheck analysis tools to figure out more, and any user can do that, it's just not being meant for users but for developers to go through the steps and documentation how to use it, it's not exactly user accessible and the information given ofcourse to an unexperience user in tech is also not helpful, but it is for advanced users community who would cobble up together enough information to point them to a general area where a workaround could be found faster and easier, which is usually how things go, a proper fix ofcourse is out of the question if something's proprietary like Windows, but in many many cases the Windows users community have found many workarounds for thousands of different Windows issues for ages.

Infact one could argue developers usually don't debug their own systems they run on, they debug software to be used by others mainly and they have a list of things they'll fix and what they won't fix so to them a few edge cases of buggy behavior isn't that of a big deal as much as it could be to some users. The philosophy of treating even enthusiast users as second/third-class citizen or rather not recognizing and addressing such users is the old and new established way of corporate thinking and it's about time some of these open-source projects hopefully change this kind of treatment. Just because I can and do play games doesn't mean I don't program, develop, 3d-sculpt, transcode video, train on flight sims, and even fire up debuggers, fiddle with rtl-sdr, raspberries, linux, you name it. The industry out there in many cases doesn't recognize advanced multi-tasking multi-field kind of users who do a wide number of advanced and workstation type stuff at the same time yet also entertainment stuff, and it drives me crazy when the hardware/software solutions sometimes make very hard distinctions and hard separations within their offerings, but the HEDT platform if it spins up to be a more prominent and significant platform it could be something that precisely covers this kind of usecase.

Also Microsoft really does not care about this type of customer, infact they're doing right the opposite, preventing people from becoming more advanced and familiar with the inner workings of a system, OS, etc because ofcourse a smart customer is an non-lucrative and problematic customer.

[skeevy420]

What would you swap in instead?

Systemd-the-init uses and tries to expose Linux kernel features in a convenient way. Systemd-the-project then builds tools exposing more Linux kernel features, built on top of the features exposed in the lower levels of the stack, all the way down to systemd-the-init.

Competing init systems are trying to be smaller, expose less functionality in the init process itself and to rely on standard POSIX features only to be useable on kernels other than Linux. So they lack features most of the tools in systemd-the-project depend on, effectively making much of the systemd-the-project tools only work on systemd-the-init.

One could implement the needed infrastructure on top of any init system in some Linux-specific layer, but so I have not seen anyone try recently. Ubuntu did it for a while for parts of the systemd-the-project stack when they were not yet using systemd, so it is definitely possible. Somebody that likes systemd-the-project, but hates systemd-the-init would be needed to write such a layer, but you are not likely to find many such people.

Currently, nothing. The systems management part of systemd does a lot more than anything else. That was kind of my point of the protocol. Systemd keeps adding more and more functionality but there isn't a clear and defined way for anyone else to make compatible alternative service management methods or tooling; like an alternative to homed that isn't locked to ext4, F2FS, or LUKS or an alternative to systemd-boot that isn't limited to GRUB's file system drivers in some instances (notably, OpenZFS).

[skeevy420]

I was talking to a group of BSD users on a mailing list after Michael posted this article and I used this term: Linux, especially Linux with SystemD, is becoming a multitool. You know also known as a swiss army knife. Sometimes I just need a really good screwdriver, or torque wrench, or a 13mm socket, or what have you. I don't need a magnifying glass, a bottle cap opener, and a tiny hard to use screw driver.

Linux, admittedly does a very good job of it, tries to be a jack of all trades- a multitool. The OS for super computers, cloud web servers, desktops, laptops, and even embedded systems. Like I said it does a good job of this but one tool can not be all things.

That's what I was trying to say in my other post. You see "systemd-xyz" is available so you know you have "xyz" tools in your box.

Fn 13mm socket

Had to replace my car battery yesterday, all the bolts were metric, and all my ratcheting wrenches are imperial

Auto-adjusting Vise grip pliers to the rescue

[tobias]

Currently, nothing. The systems management part of systemd does a lot more than anything else. That was kind of my point of the protocol.

Are you talking about systemd-the-init system here or systemd-the-project's tools around that init system? The init part seems pretty stable to me. Ok, they do add some new Linux kernel features as those become available widely enough. E.g. the latest release switched over to mostly use pidfd AFAIR.

Systemd keeps adding more and more functionality but there isn't a clear and defined way for anyone else to make compatible alternative service management methods or tooling

Who wants to do that? I have seen zero interest to copy the systemd-the-init features in or on top of any of the other init systems out there: Those are apparently all bloated, useless and a security nightmare. In fact I see no init system out there that even tries to write an init system for Linux: They all target the least common denominator POSIX instead. You bring up a hypothetical case as for systemd-the-init.

It's a different picture for the wider systemd project and the tooling it provides: There are lots of alternatives for many of the things: Network setup, clock management, DNS resolution, boot loader, you name it. Many of them are drop in replacements, many older than the systemd implementation, and some of them way more popular than the systemd options. Just look at how many more people use docker over systemd-nspawn, or how many distributions boot using grub -- many more than use systemd-boot.

[...] like an alternative to homed that isn't locked to ext4, F2FS, or LUKS or an alternative to systemd-boot that isn't limited to GRUB's file system drivers in some instances (notably, OpenZFS).

Systemd-homed is about not having data in the users home directory visible in a system as long as the user is not logged in. It uses encryption to make sure data is inaccessible while a user is logged out and relies on the kernel handling that encryption, either via fs-crypt or LUKS. So you are limited to either a filesystem with support for gs-crypt or you need to use LUKS. There is little an alternative implementation could do about that -- maybe do encryption in userspace somehow? No thank you :-)

Systemd-boot does not use any filesystem driver at all: It relies on the EFI bios to read files. That's why it is significantly simpler than grub and enough to read the kernel and initrd from the EFI partition or the extended boot partition. Once the kernel is up it can use any filesystem driver found in the initrd to mount other filesystems.

[Weasel]

Systemd-boot does not use any filesystem driver at all: It relies on the EFI bios to read files. That's why it is significantly simpler than grub and enough to read the kernel and initrd from the EFI partition or the extended boot partition. Once the kernel is up it can use any filesystem driver found in the initrd to mount other filesystems.

I like systemd-boot a lot because of its simplicity (and how bug ridden GRUB is in comparison).

But I really, really cannot understand why it's part of systemd when it has nothing to do with it. You don't even need to have systemd installed for it to work (I mean, it's obvious, the system isn't even "up" at that point during boot).

That's the problem here.

Just call it "simple boot manager" and make it completely separate project and that's it.