Announcement

Collapse
No announcement yet.

Ubuntu 14.10 Utopic Can Now Boot With Systemd

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

  • Ubuntu 14.10 Utopic Can Now Boot With Systemd

    Phoronix: Ubuntu 14.10 Utopic Can Now Boot With Systemd

    Just days after Ubuntu 14.10 opened for development, a systemd package has landed within the "Utopic Unicorn" package archive that allows the Ubuntu desktop to be booted via systemd rather than Upstart...

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

  • #2
    Why the ancient systemd version? Even the systemd-stable branch is newer.

    Comment


    • #3
      Originally posted by blackout23 View Post
      Why the ancient systemd version? Even the systemd-stable branch is newer.
      204-10 is what's in Debian sid. 208 is in Debian experimental.

      Comment


      • #4
        I'm running it right now in a complex use case with good results

        Originally posted by DanL View Post
        204-10 is what's in Debian sid. 208 is in Debian experimental.
        I've just installed systemd on my system,now booting to it by default, with networking, unlocking multiple encrypted disks, and even using the Plymouth splash screen. Booting is at least as fast as with Upstart, though it's hard to benchmark this on an encrypted system with a long passphrase.

        I ran into three issues when I installed Systemd:

        1: I had to write a system file for lightdm. As of now lightdm seems to start a bit early, causing Plymouth to stop unnecessarily soon. Plymouth does keep running after mounting the real root, and will keep running during an fsck run, though obviously without fsck progress reports.

        2: I could not get NetworkManager to run by any means except starting it from /etc/rc.local . This is a nuisance and means my bugfixes can't be so easily stored as a debian package as this requires overwriting a file.

        3: I use a custom method to run cryptsetup from the initramfs, having valid but unused entries in /etc/crypttab caused a hang that would eventually break out and continue with booting. How the devices got unlocked in the initramfs should not change the fact that an /etc/crypttab entry caused the systemd cryptsetup routines to hang on attempting to unlock devices that already existed. Therefore, it appears that the normal way Cryptsetup unlocks disks in the initramfs won't work with systemd in Ubuntu. Systemd does not know they are already unlocked since the initramfs doesn't use systemd, which means this is less an issue with systemd itself than with not using it in the initramfs. If Ubuntu does use it in the initramfs later, I will simply need to write a systemd unit to run my custom script. A fix for this would be to rename /etc/crypttab in a patch to cryptsetup, or to remove the cryptsetup units in systemd. Unknown if the latter would prevent Nemo/Nautilus/Caja from being able to call for a passphrase to unlock a device inserted later. Like I said, I am new to Systemd. My own system works fine with an empty /etc/crypttab, but what about everyone using cryptsetup's normal boot scripts on a laptop with everything but /boot on a single encrypted volume divided up with LVM?

        At some point I will need to port my custom cryptsetup work to systemd in the initramfs, unless the whole Debian family intends not to use systemd in the initramfs at all. Looking forward to the introduction of a package that will let me work on this. This is the next thing on that package's TODO list.

        One thing I don't get is all this anti-systemd hate I've been seeing, it seems to me to be potentially a very fast booter and technically seems to be a very interesting system that takes up where Upstart left off. I've heard stories of unencrypted systemd-using computers that boot about as fast as cellphones and cameras do. Yes, it's got bugs, but it's also very new code. Yes, it can do a lot of things, not just "one thing well," but that's also true of the kernel itself. Also like the kernel, it's modular and can do as little or as much as your needs for a particular system call for.

        Comment


        • #5
          Originally posted by Luke View Post
          2: I could not get NetworkManager to run by any means except starting it from /etc/rc.local . This is a nuisance and means my bugfixes can't be so easily stored as a debian package as this requires overwriting a file.
          Does NetworkManager have a service file in /usr/lib/systemd/system on Ubuntu? If not, you could try adding them to /etc/systemd/system. The Arch files look like so:

          NetworkManager.service:
          Code:
          [Unit]
          Description=Network Manager
          Wants=network.target
          Before=network.target 
          
          [Service]
          Type=dbus
          BusName=org.freedesktop.NetworkManager
          ExecStart=/usr/sbin/NetworkManager --no-daemon
          # NM doesn't want systemd to kill its children for it
          KillMode=process
          
          [Install]
          WantedBy=multi-user.target
          Alias=dbus-org.freedesktop.NetworkManager.service
          Also=NetworkManager-dispatcher.service
          NetworkManager-dispatcher.service:
          Code:
          [Unit]
          Description=Network Manager Script Dispatcher Service
          
          [Service]
          Type=dbus
          BusName=org.freedesktop.nm_dispatcher
          ExecStart=/usr/lib/networkmanager/nm-dispatcher.action
          
          [Install]
          Alias=dbus-org.freedesktop.nm-dispatcher.service
          Both are enabled, but the dispatcher service isn't running on mine. ...not sure if that's by design or what.

          Comment


          • #6
            i wish they would keep upstart. This is development time wasted.

            Comment


            • #7
              The Arch service files for NetworkManager didn't work in Ubuntu

              Originally posted by Nobu View Post
              Does NetworkManager have a service file in /usr/lib/systemd/system on Ubuntu? If not, you could try adding them to /etc/systemd/system. The Arch files look like so:

              NetworkManager.service:
              Code:
              [Unit]
              Description=Network Manager
              Wants=network.target
              Before=network.target 
              
              [Service]
              Type=dbus
              BusName=org.freedesktop.NetworkManager
              ExecStart=/usr/sbin/NetworkManager --no-daemon
              # NM doesn't want systemd to kill its children for it
              KillMode=process
              
              [Install]
              WantedBy=multi-user.target
              Alias=dbus-org.freedesktop.NetworkManager.service
              Also=NetworkManager-dispatcher.service
              NetworkManager-dispatcher.service:
              Code:
              [Unit]
              Description=Network Manager Script Dispatcher Service
              
              [Service]
              Type=dbus
              BusName=org.freedesktop.nm_dispatcher
              ExecStart=/usr/lib/networkmanager/nm-dispatcher.action
              
              [Install]
              Alias=dbus-org.freedesktop.nm-dispatcher.service
              Both are enabled, but the dispatcher service isn't running on mine. ...not sure if that's by design or what.
              I tested these, I got the same results as with the simpler service files I tried: NetworkManager started only to die about a second after Cinnamon came up. Same with IceWM, so not caused by Cinnamon. Works fine when started from /etc/rc.local , don't know why it insists on starting from there. Copying the core elements of both that script and the service file under another name
              did NOT work, strangely enough.

              Speaking of service files, the newest version of lightdm has one, and it seems to work fine except for the black screen for several seconds between Plymouth stopping and the
              desktop coming up. As good as anything I was able to come up with.

              Comment


              • #8
                Originally posted by Luke View Post
                One thing I don't get is all this anti-systemd hate I've been seeing, it seems to me to be potentially a very fast booter
                Agree. I've used Ubuntu and use to use OpenRC on my gentoo system. Switched to systemd and there is a real noticable time difference between using OpenRC and systemd. I also feel like creating unit files and setting up the desired init configuration is extremely simple with systemd. While it does have some short-comings, it is by far my favorite init system I've used thus far.

                Comment


                • #9
                  boot benchmark upstart vs systemd?

                  Anyone knows a benchmark which shows/proofs which is fastet etc? The only boot benchs i have seen are old and betwen ubuntu and fedora and ubuntu won with upstart. Is there any more recent benchmarks?

                  Comment


                  • #10
                    Originally posted by jumu View Post
                    Anyone knows a benchmark which shows/proofs which is fastet etc? The only boot benchs i have seen are old and betwen ubuntu and fedora and ubuntu won with upstart. Is there any more recent benchmarks?
                    It doesn't really matter. Both support asynchronous startup so it's depends on how good
                    config you writes and what you start.

                    Comment


                    • #11
                      Originally posted by jumu View Post
                      Anyone knows a benchmark which shows/proofs which is fastet etc? The only boot benchs i have seen are old and betwen ubuntu and fedora and ubuntu won with upstart. Is there any more recent benchmarks?
                      I have a typical Debian Testing machine, that used default sysV, with typical daemons: networkmanager, cups, gdm, cron, aumix, udev, klogd and so on.
                      Nothing fancy like Apache etc.
                      After enabling systemd migration package, I noticeably experienced at least 1/3 increase in startup speed and far far less garbage, ahem, info on the screen.

                      That said, because systemd works with socket activation, it is much more logical, self-organizing/paralleling init.
                      The only point against it is virtually "learning something new" thing. ...and BSD-too buzz (what? on servers?), if you are affected by it.
                      Last edited by brosis; 04-30-2014, 03:57 PM.

                      Comment


                      • #12
                        As far as NetworkManager and systemd, have you filed a bug against either in launchpad? I searched both, but couldn't find any.

                        That may be a good place to start, or open a thread on the ubuntu forums (but the forums may not be helpful if no devs see it, so Ubuntu or systemd on IRC might be a better option, and you can document the solution in the forums or the bug you opened, assuming you opened one).

                        I would try to help you myself, but I don't have Ubuntu installed on any of my machines at the moment.

                        Comment


                        • #13
                          Originally posted by brosis View Post
                          That said, because systemd works with socket activation, it is much more logical, self-organizing/paralleling init.
                          The only point against it is virtually "learning something new" thing. ...and BSD-too buzz (what? on servers?), if you are affected by it.
                          why don't you try learning something new like what an init system does, then insulting people that actually took the time to do so
                          just sayin

                          Comment


                          • #14
                            Originally posted by gens View Post
                            why don't you try learning something new like what an init system does, then insulting people that actually took the time to do so
                            just sayin
                            Earth is so overcrowded, that stepping on someone's butt is one the daily schedule.
                            Its not me placing that butt there, on the road of expression of a personal opinion.

                            So, if it hurts, its your butt, your placement, your problem. If I would be a tolerast, I won't be even able to walk.

                            Comment


                            • #15
                              Not sure if it really counts as a bug

                              Originally posted by Nobu View Post
                              As far as NetworkManager and systemd, have you filed a bug against either in launchpad? I searched both, but couldn't find any.

                              That may be a good place to start, or open a thread on the ubuntu forums (but the forums may not be helpful if no devs see it, so Ubuntu or systemd on IRC might be a better option, and you can document the solution in the forums or the bug you opened, assuming you opened one).

                              I would try to help you myself, but I don't have Ubuntu installed on any of my machines at the moment.
                              Although systemd is available in Ubuntu's repos, it is experimental and there primarily so Ubuntu devs can find out what packages need modification to work with it. You can bet they will encounter the NetworkManager issue quickly. My own system is forked quite a ways from default Ubuntu, even more so now that I have also migrated to dracut and systemd in the initramfs. I just spend a whole week porting both Debian's version of Plymouth (which supports Dracut but is quite diferent than Ubuntu's version) and my special unlocker for multi encrypted disks to Ubuntu with dracut and systemd starting right after the kernel is loaded. Those all work, and I've got NetworkManager staring in /etc/rc.local for now. Next on the agenda for me is to fix the Plymouth bug that forces me to kill and respawn it at the pivot-root to keep it from hanging, followed by using systemd instead of a dracut hook to start my single passphrase call multi-disk unlocker.

                              Doing all this mostly so I could get my own packages ported over in advance instead of just sweating about systemd obsoleting my previous work and forcing a do-over of unknown dificulty at an unknown time. I do have one suggestion for others though: it might be easier to port some things to systemd in advance by starting with a Fedora 20/rawhide install so you start with systemd, dracut, and plymouth working right by default. I didn't have the bandwidth to download an installer for this from home.

                              Comment

                              Working...
                              X