Announcement

Collapse
No announcement yet.

Booting Ubuntu With Systemd Went Surprisingly Well

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

  • Booting Ubuntu With Systemd Went Surprisingly Well

    Phoronix: Booting Ubuntu With Systemd Went Surprisingly Well

    Given the talk this week at the latest Ubuntu Developer Summit about transitioning from Upstart to systemd with the upcoming Ubuntu release cycles, I decided to see how well it works for opting into systemd with the current Ubuntu 14.10 development state...

    http://www.phoronix.com/vr.php?view=MTcxODY

  • #2
    Why is Ubuntu waiting 2 years when it works now?

    I've been using systemd in Ubuntu (and in the initramfs with Dracut at that) since May with only one minor issue: sometimes having to restore resolve.conf from a text file with my chosen non-ISP DNS server. Both Dracut and Plymouth required some porting on my part, and there are some plymouth bugs that I think are specific to nobody having built plymough 0.9 for Debian yet. Those are not systemd issues, but rather work that Ubuntu simply hasn't done yet.

    I got this stuff roughly working on my systems in two week of hacking, why does Ubuntu expect to take two years? They'd be better off to switch now, temporarily installing alongside Upstart but with systemd as the default until all the bugs are worked out. That way, when 16.04 comes out they would have a well worked out and totally debugged systemd setup, instead of a buggy first time attempt. By installing alongside for now, as the current systemd package available in Utopic does, they would be giving users a choice if they want to wait until this it totally finished.

    Right now the pace of development is slow in Ubuntu. Right now Dracut is at version 0.27 and does not even use systemd. I use version 0.37 from Debian, and had to get plymouth from there too to make the splash work. Just to INSTALL it without removing the whole OS because of initramfs-tools conflicts requires making a new debian package with the conflict removed from the control file. You then must rename the initramfs you make using it and tell GRUB to load that one, or else keep /boot unmounted so normal package updates don't clobber it with update-initramfs.

    If Ubuntu upstream wants my Dracut and Plymouth work I have it in debs and will gladly send it to them. Surely they could start from that baseline and come up with a better version. It's kind of crude but it works well enough to be on all my systems along with current Ubuntu Utopic systemd.

    Comment


    • #3
      Originally posted by phoronix View Post
      When booting up the Ubuntu 14.10 latest image with systemd 204
      204 is a really old version http://cgit.freedesktop.org/systemd/...d/tag/?id=v204

      If they want something really stable, they can get 208 from RHEL or from systemd-stable http://cgit.freedesktop.org/systemd/systemd-stable/

      Comment


      • #4
        Originally posted by michal View Post
        204 is a really old version http://cgit.freedesktop.org/systemd/...d/tag/?id=v204

        If they want something really stable, they can get 208 from RHEL or from systemd-stable http://cgit.freedesktop.org/systemd/systemd-stable/
        They stuck with 204 because of something related to logind or udev I think. There was an article about it awhile back.

        Comment


        • #5
          Originally posted by Ericg View Post
          They stuck with 204 because of something related to logind or udev I think. There was an article about it awhile back.
          I know they had to stick with systemd-shim v204 because of logind v205 and above need systemd as pid 1, as all the cgroup management was moved there.
          They where using a hybrid of systemd services along with upstart...


          They should be able to bump the version I would think, unless they are trying to make it co-installable with upstart...

          Comment


          • #6
            We've still got 204 in Debian unstable so maybe that contributed to their decision.

            Comment


            • #7
              I bet it's easier to use systemd on Debian than Ubuntu since on Debian it can just use the sys v scripts as fallback. Or does Ubuntu also still ship some legacy init scripts?

              Also don't get it why Canonical makes it sound like switching to systemd is a such a huge deal. For Arch Linux the transistion was very fast. Most people already used systemd from the AUR anyway.

              Comment


              • #8
                Originally posted by blackout23 View Post
                I bet it's easier to use systemd on Debian than Ubuntu since on Debian it can just use the sys v scripts as fallback. Or does Ubuntu also still ship some legacy init scripts?

                Also don't get it why Canonical makes it sound like switching to systemd is a such a huge deal. For Arch Linux the transistion was very fast. Most people already used systemd from the AUR anyway.
                Ubuntu has some upstart scripts for default things like dbus and the display managers and cron, but I think other packages like samba and apache have legacy scripts with them too...

                Comment


                • #9
                  opensuse went to systemd a bit too early I think, too much legacy fallback required. now nearly everything can be managed by systemd, it's fine, I just wish the last stragglers would catch up.

                  the only things I am still getting used to are the way things like each openvpn "service" appears as different systemd targets.

                  Comment


                  • #10
                    Originally posted by blackout23 View Post
                    For Arch Linux the transition was very fast. Most people already used systemd from the AUR anyway.
                    Seriously doubt most people used systemd from the AUR and Tom Gundersen worked hard on making the transition as smooth as it was. The other distributions would do well to have upstream developers to address their particular idiosyncrasies like Tom did for Arch Linux.

                    Comment

                    Working...
                    X