@ Gregg Bell, anyone who can endure an 18 minute boot time, probably deserves a medal for patience.

1 members found this post helpful.

Thanks Ztcoracat. Hey, I like your website. Nice giraffe!

Wow, what a story, Ardvark. No doubt God has done some amazing things with you.

Ha ha. A medal! All right! Thanks!

Don't be too quick to assume that whatever is wrong is something OP might actually have any control over. I'd be interested to have some idea where OP's delays occur, whether kernel loading, initrd loading, and/or at various points during the init process.

Starting about 18 months ago, with kernels as old as 3.16, some kernel/initrd pairs began resulting in insufferable delays simply getting init started. This has happened on two different machines, with multiple distros (only those using Dracut), even though the machines operate normally once booted, and show no signs of hardware trouble from memtest or hdparm. I've reported this at least twice on mailing lists, initially on linux-ide, then initramfs. If or where else I don't remember. The delays varied, but resulted in boot times as long as 13 minutes, and without starting X.

I've uninstalled most kernels that produced such delays, but in its current configuration on host big41, these take too long for the boot loader vmlinuz and initrd loading messages to clear, followed by otherwise ordinary (no Plymouth) inits:

Fedora 25 4.8.rc1git0.1 (roughly 3 minutes to shell prompt)
openSUSE Tumbleweed 4.7.2 (sda10)(110 seconds to shell prompt)

All these on same host boot without undo delay:

Fedora 25: 4.5.rc6.git2.1, 4.6.rc1.git0.1 & 4.7.rc3.git2.1
Fedora 24 & Rawhide (all)
openSUSE Tumbleweed: 4.7.2 (sda23), 4.6.4, 4.5.2 4.4.3, 4.3.3
openSUSE 42.1, 13.2 & 13.1 (all)
AntiX 16 4.4.8
Jessie 4.5
Kubuntu 14.0 3.16
Mageia 5 4.4.16
Stretch 4.6 & 4.2

1 members found this post helpful.

Thanks!-

Your right assuming isn't a good practice.

Do you suspect kernel regression? What other initialization processes could things be taking so long?

Do you think a new kernel is the answer?

Not highly.
That's one of the reasons why I posted my questions to those mailing lists. Another is these delays apparently happen before any logging starts, and I don't know how to gather usable clues so early.

It happened with lots of kernels. Many times, rebuilding the initrd (sometime multiple times) solved the problem only to have it resurrect in a newer kernel. Remember, my list, except for one, was only of currently installed kernels on one machine of two. It excludes virtually all the many removed in the past 18 months, and those on the other machine.

IIRC, not only did it never happen with a mkinitrd image, but it also always happened and happens on EXT4 filesystems, not on EXT3. Several times early in my attempts to pin it down I tried creating a new EXT3, rsyncing from EXT4, and the same kernels/initrds worked fine.

I'm thinking these delays are actually more common than what I wrote may have implied, just more often with much shorter delays in maybe the 2-5 second range. And, those with short delays occur on far more than two of my machines, maybe all. Once upon a time, the bootloader's kernel/initrd loading messages would flash on and off so fast it was impossible to read them start to finish. That seems to not happen any more as often as it does, but I suppose that could be a function of when the kernel decides to clear what bootloader wrote to display rather than bootloader doing its own clearing.

My primary speculation is that storage access is wrested from the BIOS later than it used to be before UEFI became common, leaving many devs using solid state drives in no position to notice anything that causes a nominal slowdown at such an early stage of IPL, while the kernels and initrds just keep bloating with new functionality. Another speculation that could play into this is that devs I think are mostly assuming or even using Plymouth, and I'm not, except on a few installations where Plymouth removal would eradicate half the installation due to idiotic deps.

I don't read code or build, limiting what I can do to identify any cause.

That stinks:-

In some cases plymouth has generated an issue with booting.
http://askubuntu.com/questions/46537...t-ubuntu-14-04

I'm wondering if it's a plymouth-upstart-bridge Issue? Or maybe the kernel thinks that Plymouth is running to fast? (something to think about)
https://ubuntuforums.org/showthread.php?t=2218100

Without seeing the boot up myself I can't pin down what is causing the delay.
I'd think that reading through the dmseg log should provide some clues why this delay for the boot.

If plymouth is the culprit than disabeling the splash screen and plymouth in grub might be the answer.
I'm still learning to read code and it's not easy. Don't build; not there yet:-

I'll be running Testing soon so I can learn and possibly learn a fix for this.
Booting shouldn't really take more than 2 min's if that.

Have you gotten a response from the mailing lists?

*buntu is one of my fewest installations, so there's no guarantee it's among those ever experiencing the problem. Most are 14.10 or older. I don't know if these ever switched from mkinitrd to dracut.

I always do the best I know how to keep Plymouth from participating in the boot process. It's not installed on any openSUSE or Fedora. Bootloader stanzas where it is installed typically have any of noplymouth, plymouth=0, plymouth.enable=0 or whatever I thought might appropriate to the distro.

All cmdlines include splash=disable or splash=0. None include quiet.

Dmesg IIRC always seems to include times that began after the delay has passed.

No useful mailing list responses.

Hurricane Hermine is about to flood here, so more will have to come later, if ever.

Sorry to hear you haven't gotten any responses.

I sincerely hope it doesn't flood:-
It's headed my way Saturday.

Stay safe guys.

11" deep in the house.

Oh God. So sorry.

Sorry mrmazda. I was really grieved when I read you message.

I hope you can rebuild.