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?
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?
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
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!
Ubuntu can read my SSD at its maximum speed of 550MB/sec...
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:
Not sure what the significance of that is...
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.
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...
I think the issue is that GRUB is taking a long time to load the kernel image.
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?
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:
- 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
And here are the first lines from the output of
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:
- And it seems even people with ARCH have this problem...