Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[Luke]

8PM update: Plymouth in dracut/systemd

Next up: I've gotten Plymouth to work in Dracut/systemd, but only in the "text" theme, and only using the Debian version hand-installed over the Ubuntu version which uses different library locations. I need to first get the Ubuntu version to work by itself, then somehow get the script themes (which include my custom one) to work. Worst case is I might have to wait for dracut to mature a bit in Debian so someone else can get systemd to run plymouth directly and with theme support. Anyway, once that happens my boot unlocker and Plymouth theme should now be drop-ins, so I have nothing to fear from Systemd.

As of 8PM May 6 I now have Plymouth working with my custom theme in dracut. Turned out I had to use the Debian version which supports Dracut and Systemd, my efforts to port it to Ubuntu's lib locations flopped for now. Only thing was-my theme's .plymouth file still referred to the old locations-and I had NOT looked in that file! Works now, though I can't get systemd itself to start it yet so scripts have to both start it, and momentarily stop it before the pivot-root or it will hang.

Good enough now to be my default booter, the rest is luxuries...

[Luke]

More results from my Systemd experiments

All this hate because someone dares to come up with new boot code! I've been playing with systemd for the past week, it's been like a new toy to me to learn my way around. Since I mantain a private package for unlocking multiple encrypted disks, I figured why not install systemd, learn my way around it, and then port my package to work with it.

OK, here's my results: With systemd on the root volume and the older Upstart/initramfs-tools initrd, it works fine so long as there are no invalid but present entries in /etc/crypttab (not used by my package. With a systemd using version of Dracut instead, I can unlock all disks and boot, but not with my own code and a single passphrase call yet, nor have I gotten my custom Plymouth theme working in Dracut's initrd yet. .

As of May 5 I sucessfully ported my "cryptall" package that unlocks all encrypted disks with one passphrase call without making a keyfile to dracut-037-1 from the Debian repos. A normal systemd/dracut boot with an encrypted root and home on an encrypted md raid normally will call the passphrase at least 4 times. I suspect a race condition between the appearance of the decrypted volumes in /dev/mapper and systemd's cryptsetup generator not finding the volume and trying again. I ran into a similar race condition in my own script when running under systemd and using the systemd password agent. This was fixed simply by slowing the script down a bit with tests to support more options. Now my code can unlock both volumes with a single passphrase call every time. Best of all, it works with or without Plymouth, and supports both LUKS and non-LUKS volumes. I will probably also drop my keyfile support and test to detect it back into this script, they are in the initramfs-tools version.

Next up: I've gotten Plymouth to work in Dracut/systemd, but only in the "text" theme, and only using the Debian version hand-installed over the Ubuntu version which uses different library locations. I need to first get the Ubuntu version to work by itself, then somehow get the script themes (which include my custom one) to work. Worst case is I might have to wait for dracut to mature a bit in Debian so someone else can get systemd to run plymouth directly and with theme support. Anyway, once that happens my boot unlocker and Plymouth theme should now be drop-ins, so I have nothing to fear from Systemd.

One security perspective: If your init is systemd but you do NOT use it in the initramfs, anyone messing with your initramfs while you are out is going to have a harder time getting their code to run after the pivot-root, especially if they bring code meant for Upstart. On the other hand, I would advise making sure your network cannot be reached early in the boot process, even if your systemd install supports early network access if you use encryption. That might be why dracut uses a separate package for network filesystems/boots.

One of the complaints has been about the volume of material that often must be used on the kernel command line. For controlling a dracut systemd booter, most of this gets written as rd.(something), like using rd.auto=1 to get raid detection but rd.luks=0 to keep systemd's native cryptsetup from running in parallel with my own unlocker. I do agree that systemd devs should insure that no command line switch used in systemd ever uses the same wording as one used by the kernel, nor overlaps that used by anything else. Meanwhile kernel devs should avoid in the future using anything like rd.(anything) for kernel functions.

[b15hop]

Why don't you just try it for yourself and make your own opinion? A VM is cheap....

I don't use vm, I just try on a separate machine.

[gamerk2]

I was talking about the guy who said : " If SystemD is still this bad then maybe it should still be considered experimental.".
And the systemd guys can't change the purpose of a flag/var/etc... (though they can ask, which it looks like they did). However it doesn't really changes from my answer : if I make a software A that changes its functionning according to flag A_FLAG, it is MY responsability to ensure that whatever is put into A_FLAG, my software still works as intended (even if in some cases it means/might be easier to change what is intended instead of changing the actual software)...

This. If some other piece of software abuses your functionality, that's not your problem. You, the developer, are ONLY responsible for making sure that for any possible Input, you output the correct data.

[doom_Oo7]

But we aren't really talking about a C function here, we are talking about a boot flag. Things like boot flags, environment variables, and other configuration settings do have intended purposes.

I was talking about the guy who said : " If SystemD is still this bad then maybe it should still be considered experimental.".
And the systemd guys can't change the purpose of a flag/var/etc... (though they can ask, which it looks like they did). However it doesn't really changes from my answer : if I make a software A that changes its functionning according to flag A_FLAG, it is MY responsability to ensure that whatever is put into A_FLAG, my software still works as intended (even if in some cases it means/might be easier to change what is intended instead of changing the actual software)...

[TheBlackCat]

I don't really see how a well-coded C function can be used for something other than it's purpose...

But we aren't really talking about a C function here, we are talking about a boot flag. Things like boot flags, environment variables, and other configuration settings do have intended purposes.

[doom_Oo7]

So you're saying that using a feature for other than it's intended purpose is fine

I don't really see how a well-coded C function can be used for something other than it's purpose...
For instance, I just took a random function in one of the latest commits : http://cgit.freedesktop.org/systemd/...rtnl-message.c

Let's have a look at

message_new

. I'm not expert coder (and I really prefer the static correctness you can get from C++), but from what I can see :

• Every function call's return is checked
• There are asserts for case where it may go wrong

So there certainly might be corner case bugs or missing asserts, but to me the code seems good and the functions seems to have well defined invariants. I just find the documentation lacking however (but I looked on other files and it seems they prefer to document everything on the wiki : http://www.freedesktop.org/wiki/Soft...journal-files/ is referred in journal-*.h for instance)...

There are also good tests : http://cgit.freedesktop.org/systemd/...nl/test-rtnl.c
And I suppose it's the case for other modules.

[Nobu]

So you're saying that using a feature for other than it's intended purpose is fine and you should be able to expect it to work, even when the tests that were written for it (if any) were written with the expectation that it would be used for something else?

I'm with you as far as testing your code to make sure it works the way it's intended, but you can't expect everyone to be able to read into the future and predict every way a particular function will be misused and abused.

Anyway, in this case it was more a case of two pieces of software using the same keyword to perform some function, not so much one piece of software abusing another's feature. I misspoke there.

[doom_Oo7]

You can't expect software to work well when you abuse its features. This goes for systemd and the Linux kernel, and any software, honestly.

This is blatant bullshit. If it's modular you can just have good tests and good continuous integration for everything you do... (Of course making them requires a good spec and time, lots of)

[doom_Oo7]

A man of my own heart.

Off topic - I guess if this were like a space ship, we would all choose the reliable ship vs the one with the most cool features or fastest ETA time.

Otherwise on topic .. If SystemD is still this bad then maybe it should still be considered experimental.

Why don't you just try it for yourself and make your own opinion? A VM is cheap....