Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by doom_Oo7 View Post
    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.

    Comment


    • Originally posted by TheBlackCat View Post
      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)...

      Comment


      • Originally posted by doom_Oo7 View Post
        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.

        Comment


        • Originally posted by doom_Oo7 View Post
          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.

          Comment


          • More results from my Systemd experiments

            Originally posted by Luke View Post
            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.

            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.
              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...

              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...

                Comment

                Working...
                X