Page 25 of 25 FirstFirst ... 15232425
Results 241 to 247 of 247

Thread: Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

  1. #241
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    303

    Default

    Quote Originally Posted by Nobu
    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
    Code:
    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.

  2. #242
    Join Date
    Feb 2011
    Posts
    1,214

    Default

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

  3. #243
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    303

    Default

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

  4. #244
    Join Date
    Jun 2012
    Posts
    355

    Default

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

  5. #245
    Join Date
    Mar 2007
    Location
    West Australia
    Posts
    368

    Default

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

  6. #246
    Join Date
    May 2013
    Posts
    569

    Default More results from my Systemd experiments

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

  7. #247
    Join Date
    May 2013
    Posts
    569

    Default 8PM update: Plymouth in dracut/systemd

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •