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

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

                    Working...
                    X