9

Update 9

I decided to try an experiment. I removed the SSD from my desktop, and temporarily put it into my Dell Latitude laptop. Lo and behold, it loaded the initrd on an order of magnitude faster, shaving 6 seconds off the boot time...

I'm a little confused now... maybe GRUB has an issue with my motherboard's chipset?

Update 8

So I noticed something interesting about the HDD activity light. When loading the initrd, it's almost as if the light is being PWMed at a 10% duty cycle or something. This makes me wonder if GRUB's read is not optimized, maybe something like it's doing an OS call to read each byte rather than reading the image as a byte stream?

enter image description here

Update 7

It appears that loading the initial ramdisk is a large part of the issue.

Inside GRUB, I pressed C for the manual command prompt. I then proceeded to type every single line from my default configuration in one at a time (inputting those UUIDs was painful!), and noted the time the command took at complete. Here's what I found:

  • Most of the commands completed instantaneously
  • The command to load the kernel took about one second
  • The command to load the initial ramdisk took 7 seconds

After typing in all the lines from the config file, I then proceed to run boot. From the time I hit enter to the time the login screen appeared, it took about 7.5 seconds.

Of interest is the fact that the initrd image it's loading is 36MB. So if it took 7 seconds to load, then it's only reading it at 5MB/sec!

The disk activity light on my tower stays on for the entire 7 seconds...

Also here's an interesting snippet from the Wikipedia page about initrd:

Other Linux distributions (such as Fedora and Ubuntu) generate a more generic initrd image. These start only with the device name of the root file system (or its UUID) and must discover everything else at boot time. In this case, the software must perform a complex cascade of tasks to get the root file system mounted

Update 6

Nathan Osman requested the boot time in single-user mode in chat.

From the time I hit F10 in GRUB to the time the prompt appears, it takes 13 seconds.

Also, I was talking to Zanna and Rinzwind in chat and they both have an 8-second startup from the time the hit the power button. My 20 seconds is from GRUB. If I counted POST time, it would be even longer!

Update 5

Ubuntu can read my SSD at its maximum speed of 550MB/sec...

enter image description here

Update 4

So I removed the quiet splash $vt_handoff parameters from the boot command in GRUB on my laptop (keep in mind this laptop does not have an SSD), and noticed a very interesting thing during the boot sequence:

It hangs on this line for 15 seconds:

[    4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped

Here's a (low quality) picture:

enter image description here

Not sure what the significance of that is...

Update 3

I timed the bootup of one of my other machines running 14.04 (keep in mind this machine doesn't have an SSD), and from the time I hit enter in GRUB till the login screen shows up, it takes 40 seconds.

After hitting enter, it sits at that same blank purple screen for 20 seconds, after which the Ubuntu animation loads and it takes another 20 seconds before landing at the login screen.

I looked at the output from dmesg, but I can't quite tell where it finished booting. I think it finished at 25 seconds. Here's the last few lines:

[   24.916824] wlan0: associated
[   24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   25.215550] init: kdm main process (869) killed by TERM signal
[   25.441216] vboxdrv: module verification failed: signature and/or  required key missing - tainting kernel
[   25.445587] vboxdrv: Found 2 processor cores.
[   25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[   25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[   25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[   25.476940] vboxpci: IOMMU not found (not registered)
[   33.174926] init: plymouth-upstart-bridge main process ended, respawning
[   36.495811] init: anacron main process (933) killed by TERM signal

If I interpreted it correctly, it seems to be a universal GRUB issue.

Update 2

I was able to confirm that it is a GRUB issue by setting the background color of GRUB to green by using the command line accessed by pressing C when in GRUB.

When I hit enter, I get a blank green screen for ~15 seconds before the Ubuntu boot animation loads...

Update

I think the issue is that GRUB is taking a long time to load the kernel image.

Question

I have installed Ubuntu 16.04 on my Samsung 850 Pro 512GB SSD, and I can't understand why my boot time is 20 seconds. (From the time I hit enter in GRUB). Keep in mind that the 20 I am referencing is 17 to the login screen, and then another 3 to the desktop)

Also, not sure if this is relevant or not, but:

  • Ubuntu is installed in MBR mode, because I despise UEFI.
  • I have the proprietary Nvidia drivers installed

Looking at the image generated by systemd-analyze plot > bootimage2, my startup apparently took 3 seconds?

enter image description here

And looking at dmesg, my startup apparently took 4 seconds. But I timed it with my stopwatch and it took 20 seconds! (Not including POST time) Again, keep in mind that the 20 I am referencing is 17 to the login screen, and then another 3 to the desktop)

Here's how the startup sequence goes:

  • POST
  • GRUB loads
  • I start my stopwatch as I hit ENTER
  • I get a blank purple screen for ~15 seconds
  • I see the Ubuntu boot animation for two seconds
  • I land on the login screen
  • I stop the stopwatch
  • I enter my password, hit enter, and start my stopwatch again.
  • After 3 seconds I land on the desktop
  • I stop my stopwatch again.

Here's the complete output from dmesg: http://paste.ubuntu.com/23955108/

And here are the first lines from the output of systemd-analyze blame:

   365ms dev-sda5.device
   327ms networking.service
   287ms accounts-daemon.service
   286ms ModemManager.service
   233ms systemd-logind.service
   216ms apport.service
   213ms grub-common.service
   209ms ondemand.service
   200ms irqbalance.service
   183ms speech-dispatcher.service
   178ms apparmor.service
   160ms gpu-manager.service
   148ms thermald.service
   148ms pppd-dns.service
   146ms systemd-user-sessions.service
   142ms alsa-restore.service
   140ms console-setup.service
   137ms rsyslog.service
   105ms NetworkManager.service
   104ms upower.service
   102ms avahi-daemon.service
   100ms systemd-udev-trigger.service

These people have the same problem:

Any ideas?

You'reAGitForNotUsingGit
  • 14,809
  • Comments are not for extended discussion; this conversation has been moved to chat. – Thomas Ward Feb 10 '17 at 19:34
  • I also posted a question on slow boot but it's gone from 29 seconds to 15 seconds which is now acceptable for a slow Kingfast mSata III SSD on a Sata II bus: http://askubuntu.com/questions/864277/is-initrd-img-grubs-loading-initial-ramdisk-slowing-down-my-boot – WinEunuuchs2Unix Feb 14 '17 at 01:29
  • @WinEunuuchs2Unix - How were you able to get GRUB to tell you when it was done loading the initramfs? – You'reAGitForNotUsingGit Feb 14 '17 at 04:24
  • @AndroidDev I didn't do anything special other than setting up boot chart and using systemd-analyze blame. The strange part is Grub was stuck on "loading initial ram disk" for about 10 seconds when it should be a split second because of file size. Then the lag just went away. Perhaps it was a kernel update? Maybe changes I made to plymouthd I'm not sure. – WinEunuuchs2Unix Feb 14 '17 at 04:29
  • Did you try to low down the plymouth-... a bit? SSD may be too fast ;^) See http://www.unrelatedshit.com/2014/07/30/kvm-too-fast-for-plymouth-upstart-bridge/ – ubfan1 Apr 25 '17 at 17:11
  • @ubfan1 - I'll have a look at that and report back. – You'reAGitForNotUsingGit Apr 25 '17 at 18:49
  • @ubfan1 - Well, I don't have that file on my 16.04 install. Also keep in mind that error which was mentioned in your link only occurs on my laptop, which is not the computer in question. – You'reAGitForNotUsingGit Apr 26 '17 at 17:10
  • I do use UEFI/gpt on my 250GB Samsung SSD 850. systemd-analyze Startup finished in 2.344s (kernel) + 8.799s (userspace) = 11.143s – oldfred Apr 26 '17 at 18:01
  • @oldfred - If you time it with a stopwatch, how long is it from when you hit enter for "Ubuntu" in GRUB till the login screen appears? – You'reAGitForNotUsingGit Apr 26 '17 at 18:05
  • Probably close to the 11 sec or maybe less. I have 3 sec delay in UEFI, 3 sec delay in grub and when new kernel comes down reboot to back to working is about 20 sec. – oldfred Apr 26 '17 at 19:19
  • @oldfred So that means your actual boot time is 5 seconds, because 11 - 3 - 3 = 5... – You'reAGitForNotUsingGit Apr 26 '17 at 19:43
  • The 11 does not include UEFI as that is before system even starts booting and I often hit enter before 3 sec for grub is up. But boot is quick. I still see a few things in logs that probably could be resolved to make it faster, but quick enough not to be terribly interested in digging into those issue now. – oldfred Apr 26 '17 at 21:26

1 Answers1

1

If GRUB isn't on the SSD ( which it should if properly configured during the installation ), then just having the SSD there will take GRUB time to recognise it, but it will not in any way decrease boot time, actually exactly the opposite. What you should do is make the computer boot from the SSD, by changing your BIOS boot order. Note that you also have to reinstall GRUB on the SSD. Although in some cases like my laptop you can't select SSD as the boot device from the BIOS, then you are stuck with going to the HDD, loading RAM, then going to the SSD.

Also this is what I think happens, but I don't fully know your laptop or desktop configuration, so this is all I can help with.

Hope this helps. :)

Mihail Mihov
  • 170