Canonical Once Again Aiming To Improve Ubuntu's Boot Speed

[Nille]

Debian 9 on an Apollo Lake j3455 with and Sandisk SSD

Startup finished in 15.245s (firmware) + 6.017s (loader) + 2.561s (kernel) + 1.979s (userspace) = 25.803s

[caligula]

I'm on 17.10 and they've kept true to their promise. Though I of course welcome more improvement.

$ systemd-analyze time
Startup finished in 6.942s (kernel) + 2.112s (userspace) = 9.054s

7 year old Intel system + some other desktop distro with dual gaming GPU, ethernet and wifi network interfaces, internal and USB sound cards, several game controllers etc.:

$ systemd-analyze
Startup finished in 6.260s (firmware) + 1.023s (loader) + 1.734s (kernel) + 1.118s (userspace) = 10.136s

I could speed up the firmware + loader 2 to 3 seconds, but I want to be able to boot other kernels in case an update fails.

[Charlie68]

I do not have the obsession with boot time! My notebook is equipped with SSD and the times are fast enough, I do not spend the day turning on and off and it is not a few seconds more that creates problems, the important thing is that it works well.

[leipero]

7 year old Intel system + some other desktop distro with dual gaming GPU, ethernet and wifi network interfaces, internal and USB sound cards, several game controllers etc.:

$ systemd-analyze
Startup finished in 6.260s (firmware) + 1.023s (loader) + 1.734s (kernel) + 1.118s (userspace) = 10.136s

I could speed up the firmware + loader 2 to 3 seconds, but I want to be able to boot other kernels in case an update fails.

How could you speed up firmware? The only thing I've tried is "fast boot" and it does help, but not as much..., for loader i get it, not sure of hidden timeout from GRUB is counted or not.

Normal boot (GRUB timeout 1 sec):

Startup finished in 10.053s (firmware) + 1.547s (loader) + 1.684s (kernel) + 1.810s (userspace) = 15.096s
graphical.target reached after 1.756s in userspace

Fast boot enabled (GRUB timeout 1 sec):

Startup finished in 9.169s (firmware) + 1.312s (loader) + 1.580s (kernel) + 1.884s (userspace) = 13.946s
graphical.target reached after 1.831s in userspace

As you can see, benefit of "fast boot" is not enough to justify using it in my case, especially if component such as USB or PS/2 init is disabled, you can't even enter the UEFI. I was lucky that by using efibootmgr and changing boot order UEFI would detect change and disable "fast boot" temporary so I could enter UEFI and disable the damn thing lol. So for anyone willing to try "fast boot" or equivalent, that trick might not work for you, be sure you saved profile because you might end up reseting UEFI with jampers at worst case.

[Pajn]

Startup finished in 1.733s (firmware) + 15.831s (loader) + 4.964s (kernel) + 36.509s (userspace) = 59.039s

graphical.target @29.819s
└─multi-user.target @29.819s
  └─docker.service @24.270s +5.549s
    └─network-online.target @24.259s
      └─systemd-networkd-wait-online.service @1.571s +22.687s
        └─systemd-networkd.service @1.546s +23ms
          └─network-pre.target @1.545s
            └─ebtables.service @1.490s +55ms
              └─local-fs.target @1.481s
                └─var-lib-docker-aufs.mount @25.085s
                  └─dev-sda2.device @143ms +1.278s

Grub hangs(literally hangs, I can't press anything) for about 15 seconds which is quite horrible and then networkd stalls for 22s and docker for 5s but apart from that I'm pretty happy with the current boot experience.
I would rather have them focus on making Gnome usable or resurrect Unity.

[Danny3]

I've got an 7 seconds boot on a fresh install of Ubuntu MATE 14.10 or 15.04, I can't remember exactly which version.
Since then, it has slowed down considerably.
I've tried to improve the boot time myself looking at
systemd-analyze blame
And I saw that the newly introduced 'apt-daily.service' takes a huge hit in boot performace.
Searching for finding out what exactly this service is and what it does got me to:
https://askubuntu.com/questions/8004...service#897432
I've disabled it so I could get some of the previous boot speed.
I don't understand how can the developers put such a service to run at boot time.
And I don't understand why the developers think it's a good Idea to auto-update stuff behind my back.
Since Microsoft is pushing crap down the pipe to everyone that has auto-update turned on, I don't think auto-updating stuff is a good idea anymore.
Evern if I would like it, I would still want to be asked first about such a feature.
I hope Canonical removes or at least disables this service running this service at boo time.
I hope Canonical also stops turning on by default the Bluetooth on my laptop
I lamost never use Bluetooth and when I need I can turn it on myself like on Windows.
This probably slows down the boot a little too.

[leipero]

Danny3 Last time I've installed Ubuntu, sudo apt-get purge unattended-upgrades would solve the problem of "updating behind my back", I remmember having serious corruption of apt because of it. I'm not sure if Ubuntu still uses it.

[dungeon]

Even Debian 9 enabled this by default, seems to be part of the standard Desktop experiences nowdays

As of Debian 9 (Stretch) both the unattended-upgrades and apt-listchanges packages are installed by default and upgrades are enabled with the GNOME desktop.

https://wiki.debian.org/UnattendedUpgrades

You can set it up how you like or disable it in config file, so it is not a big issue

[ElectricPrism]

Who remembers the days when booting a system would take at least 40 seconds. Around 10 or less is not such a big deal to me.

Of course if a person wanted to put money into that sort of thing I assume NVME M.2 would be a great first step at cuting that boot time down.

[johnc]

Plymouth doesn't even work in 16.04, an LTS. How about maybe fixing that so their shit doesn't look all retarded?

Or am I in crazy talk territory again?