Originally posted by doom_Oo7
View Post
Announcement
Collapse
No announcement yet.
Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
Collapse
X
-
Originally posted by TheBlackCat View PostBut 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)...
Comment
-
Originally posted by doom_Oo7 View PostI 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)...
Comment
-
More results from my Systemd experiments
Originally posted by Luke View PostAll 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. .
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.
Comment
-
8PM update: Plymouth in dracut/systemd
Originally posted by Luke View Post
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.
Good enough now to be my default booter, the rest is luxuries...
Comment
-
The only good Systemd: https://www.without-systemd.org/
Congratulations to Lennart Poettering for landing a job position at Microsoft, he will fit like a glove with their developer culture.
When was the last time Lennart did something half way and left a mess behind? In all his projects, of course: Avahi, Pulseaudio, Systemd...
- Likes 1
Comment
Comment