Announcement

Collapse
No announcement yet.

Systemd 217 Updated In Debian & Soon Making Its Way To Ubuntu 15.04

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

  • Systemd 217 Updated In Debian & Soon Making Its Way To Ubuntu 15.04

    Phoronix: Systemd 217 Updated In Debian & Soon Making Its Way To Ubuntu 15.04

    Users of Debian and its derivatives can soon expect to find systemd 217...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It was a mistake

    I like the idea of having systemd in debian, but I think they put it too late in the development cycle. I think they should have released Jessie first, and only then change to systemd.

    Comment


    • #3
      Originally posted by rastersoft View Post
      I like the idea of having systemd in debian, but I think they put it too late in the development cycle. I think they should have released Jessie first, and only then change to systemd.
      The systemd updates in ArchLinux are usually quite painless. I wouldn't expect breakage in Debian due to the update -- as long as they don't start relying on new features as e.g. the new console implementation.

      Comment


      • #4
        Originally posted by oleid View Post
        The systemd updates in ArchLinux are usually quite painless. I wouldn't expect breakage in Debian due to the update -- as long as they don't start relying on new features as e.g. the new console implementation.
        They were talking about the initial switch to systemd in debian, not the update to the package. And I'm sure you know how the initial switch to systemd went for arch (horrible. it went horribly)

        Comment


        • #5
          Originally posted by Daktyl198 View Post
          They were talking about the initial switch to systemd in debian, not the update to the package. And I'm sure you know how the initial switch to systemd went for arch (horrible. it went horribly)
          Well, I have a machine running Jessie and the current version in use works fine. I don't expect new bugs due to the update.

          Comment


          • #6
            Originally posted by oleid View Post
            Well, I have a machine running Jessie and the current version in use works fine. I don't expect new bugs due to the update.
            Jessie won't get this update, it will always be 215. 217 went to experimental instead of unstable (sid) due to the freeze

            Comment


            • #7
              Originally posted by rastersoft View Post
              I like the idea of having systemd in debian, but I think they put it too late in the development cycle. I think they should have released Jessie first, and only then change to systemd.
              Their policy says that everyone must still maintain sysvinit scripts for jessie, so in case there are some issues, they can just recommend using sysvinit for one more release. However, not switching to systemd now would have forced them to maintain the scripts for two releases, and nobody wants that kind of punishment.

              Comment


              • #8
                Originally posted by Daktyl198 View Post
                They were talking about the initial switch to systemd in debian, not the update to the package. And I'm sure you know how the initial switch to systemd went for arch (horrible. it went horribly)
                Went perfectly fine for me o.O I even switched ahead of the official switch
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #9
                  Originally posted by rrohbeck
                  Let's hope it gets backported to jessie. Systemd still quite brittle - if anything goes wrong you can expect an unbootable system (including single user mode.) I have an unbootable freshly installed jessie on another disk and I can't figure out what's wrong. Seems to have something to do with bcache.
                  My experience is that anything that is normal and working now suddenly is "you should have read the systemd manual, because now that is illegal in fstab". So far all my systems went unbootable due to using labels, or disk-by-id's in the fstab, that were not resolved yet because the label and uid and other udev stuff starts at a later moment in the systemd setup, but works just fine under the systemv part.
                  LABEL= does not work in systemd setups, /dev/disk/disk-by-* also does not work. Primary devices like /dev/sda or /dev/mmcblk0p2 do work.
                  And my latest system doesn't even give me clues about why he doesn't like my fstab.
                  But after 120s it gives up on trying to mount something I didn't ask it to.
                  At least it did load the hiddev, so I could easily switch back to sysv-core.
                  But it will probably be ironed out once I have the time to figure that out and file a bug report. It is not the only thing that keeps systems from booting. My previous system on my gaming rig was ubuntu, and after each upgrade it comes with an initrd that refuses to boot from a degraded raid array.
                  "Your raid array is degraded, I assume you do not want to boot, if you want to continue booting, press any key, and only after you pressed the key we will load the keyboard driver (usb-hid)".

                  Comment


                  • #10
                    Originally posted by Ardje View Post
                    My experience is that anything that is normal and working now suddenly is "you should have read the systemd manual, because now that is illegal in fstab". So far all my systems went unbootable due to using labels, or disk-by-id's in the fstab, that were not resolved yet because the label and uid and other udev stuff starts at a later moment in the systemd setup, but works just fine under the systemv part.
                    LABEL= does not work in systemd setups, /dev/disk/disk-by-* also does not work. Primary devices like /dev/sda or /dev/mmcblk0p2 do work.
                    What block devices are we talking about? Mounting by labels or UUIDs works fine here. They even work for encrypted block devices as I use them in my laptop -- not tested in Debian, however in Arch Linux.

                    Comment

                    Working...
                    X