Mysterious 8 second delay in boot after grub
 

I have installed Fedora 23 (KDE spin) on an HP Prodesk mini 600 G2. There is one problem I can't quite figure out, though.... after grub comes up, I press <enter> on any kernel to boot, the screen goes black with a blinking underscore cursor and then there is a mysterious 8 second delay. There is no hard drive/SSD activity during that period. Then after, BAM, there is a flurry of activity over the next 4 seconds and it is finished booting. Try as I may, I can't figure out what that delay is. But I know it shouldn't be there. Even if it were just waiting on something, if I had SOME message telling me what it is doing, that would be helpful. I am doing nothing special. No RAID, no encryption, just two partitions (root and swap).

Things that made no difference: I uninstalled Plymouth.I tried UEFI vs. Legacy. I tried a Fedora live boot DVD instead of booting from the SDD install. I tried same thing with USB key boot. Disabled a bunch of stuff like abrtd and ModemManager. Removed the "quiet" flag in the kernel invocation. Rebuilt with dracut. I even tried booting 23 on our Lenovo laptops (a totally different machine with different chipset and other hardware) and on some Intel NUC's and had the same delay. On our Intel NUC, using Fedora 21, there is the same delay but only 4 seconds (???!!!) But if I try a different distro, like Archbang, there is no such delay at all.

I thought maybe "systemd-analyze" would help, but it doesn't show that delay... it says "4.3 seconds" which is the time AFTER the 8 second delay.... further indicating the delay is after/during grub but before loading the kernel. My Internet searching has produced nothing. Even if I can't get rid of the delay, having some message on the screen would be useful because it looks like the machine is dead during that period. Any help or ideas appreciated. Thanks

When you hit <enter> in grub it loads the selected kernel and initrd and jumps to the kernel. The kernel initializes some stuff, unpacks the initrd and starts the init that it finds there. Init in the initrd loads any driver modules that need to be running but aren't built in, mounts the root filesystem, and starts the init system (sysvinit, upstart or systemd). Then your system is running.

I suspect the delay is the init in your initrd doing something. Since its generic, it is likely probing for hardware that you don't have. You can find info on the web for how to decompress it (it should be in gzip format), mount it and take look at what it does. I haven't done that lately with a Fedora build.

Here's some old info. Not sure how applicable to recent Fedora:
https://www.ibm.com/developerworks/library/l-initrd/

Thanks for the info. But if it has actually loaded the kernel, and the delay were in the kernel probing for something, wouldn't that have shown in the "systemd-analyze"? This is what I read:

"systemd-analyze time prints the time spent in the kernel before userspace has been reached, the time spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system userspace took to initialize." (see also https://en.wikipedia.org/wiki/Linux_startup_process which is interesting)

So that is why I suspect it is either in grub, or really, really early in the kernel load that can somehow hide from systemd-analyze (is that possible?) And if it is pre-kernel load, initrd won't be a factor.

Hmm... I just found something that might be useful here: https://wiki.archlinux.org/index.php...ot_performance

"Bootchart: Add this to your kernel line: initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart After collecting a certain amount of data (configurable) the logging stops and a graph is generated from the logged information. This graph contains vital clues as to which resources are being used (by default I/O, CPU utilization and kernel init threads), in which order, and where possible problems exist in the startup sequence of the system. It is essentially a more detailed version of the systemd-analyze plot function."

Perhaps that starts sooner (or perhaps not)... but might be worth a try.

I'd also look at the associated grub line that exists with this kernel choice.

I guess it could be that some part of the line has an issue.

Yep, tried a slew of different things in grub- no change. Even replaced grub with isolinux- no change. Meanwhile, I tried Fedora 21 and it does the same thing! Tried bootchart with "initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart" no additional help. Fedora 21 and 23 exhibit the same delay now on 3 different kinds of machines. Acts the same if booted live on USB, or live off a DVD, on installed on a SATA SDD or M.2 PCI card. This is really annoying! I know I should give up, but it really irks me.

fedora should have the same standard 3 or 4 sec countdown for the current kernel
-- this is normal , and it is set in the "grub.conf.d "

as for things taking extra time

a 30 to 45 second boot time is average

systemd-analyze will show that

i like using the SVG image output to "look" at it and see what is bogging it down

the Arch linux wiki is a GREAT TOOL , even for other distros
https://wiki.archlinux.org/index.php...ot_performance

the above REPLACED the old "bootchart"

Correct, but that is not the time I am talking about. I am talking about after grub. There is an 8 second delay where the computer does absolutely nothing.

This system takes 4 seconds to boot in any other distro I tried except Fedora. In Fedora, there is an 8 second delay and after that it takes 4 seconds.

Yes. On this system, systemd-analyze will show 4 seconds, with no trace of the 8 seconds of "hang" after grub.

Their documentation is fantastic, I use it all the time.

Yep, that is the link I posted in my #3 post on the thread...

so you are not power off / on booting
But using hibernate

what graphics driver is used for the 3d card ( if one)

?

No, this is from power off/on. It is not hibernate.

Integrated Intel (915)

Not that it really matters, but attached are the systemd-analyze bootcharts

Hi!

I am facing the same issue with Fadoa 23 on my Dell 14R 5420. I was running fedora 18 for a long time and there was no such problems. Last week I upgraded my laptop with a new SSD. Also, the DVD drive was replaced by a hard drive caddy, which now contains my old hard drive. I installed Fedora 23 on the SSD and grub automatically managed to find windows7 on the old hard drive. Everything was fine, until yesterday. I don't exactly remember when it get changed.

Now there is a time delay of 12 seconds from grub to boot. There is no information from systemd-analyse time. I am afraid that systemd-analyse doesn't even know anything about this 12 seconds. I have checked bootlog from journalctl, but no joy. Using the stop watch on the mobile phone I did some experiments and found that, boot logs starts after this 12 seconds.

Also, in my case this delay is absent when rebooting.

Thanks for your time.

That is interesting feedback, but when I reboot this machine (alt-control-del or "reboot") the 8 second delay is still there. So it might be yet another problem.

Many months and many hundreds of Fedora updates with no change. Fedora 24 comes out and the delay doesn't occur in 24.

Turns out there were additional BIOS updates for the HP mini's which I missed. Installed them and, to my surprise, the 8 second delay is now completely gone in Fedora 23! I tried several tests to make sure it wasn't any Fedora 23 updates, and it wasn't. No idea why it helped, but at least the problem is finally solved on this platform. I think it must be a combination kernel/hardware-BIOS issue.

Hi!

Thanks for the information. I installed Fedora 24 and the issue seems to be gone. :) Now my laptop boots in less than 15 seconds..

Have a nice day!

The delay reappeared!
 

Update!

The same problem reappeared today. Yesterday I did the installation of F24 and everything was fine. I installed all updates and rebooted several times. There was no issues at all. But, when I switched on the laptop today morning, the delay reappeared again. :(

So In my case even the Fedora upgrade could not solve this issue. Then, I suspect problem is with the bios.