agba was suggesting i start a new thread concerning this problem, which seems to have
started when slackware-current started using the 5.4 series kernel. First off the graphics
crapped out necessitating the use of nomodeset in my /etc/default/grub file and that helped,
than i found the boot up paused for two minutes at about the point eth0 initialized (e1000e)
and i thought it was the driver, no sorry it didn't seem so because i tried blacklisting the
driver and still obtained a 2 minute pause.
My motherboard is an asus rog strix z390-e gaming motherboard with an nvidia rtx 2060
graphics card. I am also running linux-5.4.6 kernel as of now. on my slackware-current
and i dual boot slackware-14.2 64 bit multi-lib which has no problem running on this systems
hardware with a linux kernel 4.4.202.
If any one has any suggestions or ideas on how to resolve this issue it might help slackware-current developement. Maybe it was too soon to to go to a 5.4 series kernel,
than again this is slackware-current after all.

Perhaps. I'm running Slackware64-current on three desktops and three laptops; they're all running the 5.4.6 kernel. No issues to report.

As I have mentioned on another thread I am also experiencing this 90 second pause in booting (currently with 5.4.5). My 'safety' kernel, which is 5.3.11, does not experience this issue. FWIW I compiled 5.3.11 but I doubt this has anything to do with this issue...

Edit: Just rebooted to double check and sure enough 5.3.11 boots fast and sure with no pause...

Others have had problems with pauses in the boot up sequence and also graphics problems requiring "nomodeset" at boot up. Perhaps some sort of regression in the code.
I can't see any problems in /var/syslog or dmesg.

It looks like an issue with the Random Number Generator (crng) that takes time to collect entropy. To test if it is the source of the problem, you can try to press keys on the keyboard during the boot (e.g. press backspace repeatedly) and see if the pause is shortened. You may also find a message with "crng init done" in the output of dmesg around (probably just after) the pause.

1 members found this post helpful.

Yeah i obtained this:
dmesg | grep crng
[ 0.138800] random: crng done (trusting CPU's manufacturer)
so it looks like the boot up was done. pretty early with crng and the boot up was delayed about the same,
and i couldn't see any mention about crng in /var/syslog either.

Nevermind. It didn't fix it. I think moving the mouse on boot might give it more random data or something and that makes it not stall.

First off i use grub not elilo which would be needed as i use uefi (/boot/efi with a vfat partition mounted on it). Using elilo causes me instability
in virtual terminal switching which is solved when i use grub for some reason (elilo is not as actively maintained as grub it would seem). Funny i would
need grub with my hardware but there you have it.

I saw suggested above that removing 'compact' in /etc/lilo.conf might rectify the problem but this was not of use on my computer. Instead I received a colossal wait until 'BIOS Data check was successful' as well as a 2 minute wait after USB mounting

I would dearly like to solve this issue which did not exist in kernels previous and including 5.3.11. I am tempted to build some point releases after 5.3.11 to find where the issue crept in...

I'm quite certain anyone here is already fundamentally aware of the nature of computer "hangs" but I find it useful and instructive to re-connect with those fundamentals as a means of reminding, clarifying, and narrowing the field.

I wouldn't be at all surprised if taking a few minutes to re-visit fundamentals triggers some memory of what could be the cause.

https://en.wikipedia.org/wiki/Hang_(computing)

Just to repost information from a previous thread that deals with the 90 second delay: a snipped section from dmesg showing where the delay happens consistently on every bootup:

Lots of hits on 'Linux 90 second boot delay' but nothing useful yet...

Hmmm...no delays here. just updated 2 boxes: (1) Lenovo T510 laptop intel i7 M620 (2) Ryzen 7 3800X mini-ITX, X570 mobo + Radeon RX590 GPU. No pauses noticeable on boot. The Ryzen 7 cube boots up in about 10 seconds to console login prompt after UEFI BIOS.

No USB or other delays observed so far. Even Network manager starting to work a bit better.

So the question should be considered: Is Slackware + 5.4.x having boot or other delays, or is there something funky with certain motherboard hardware?

There is another heatwave coming here over the next few days so I am going shelter inside in the air-con and search out when this started happening shortly after 5.3.11 (my 'safe' kernel while running -current) by compiling and testing the numerical releases after this. A little painful but perhaps useful.

It has been suggested elsewhere that the 90 second delay sounds like a timer that goes for its full length before giving up and allowing boot to continue. I suspect nothing Slackware specific, possibly your second choice of kernel vs certain hardware...

Edit: Well looks like I was talking a certain amount of crap! I have just finished compiling and running every version of 5.3.xx culminating with 5.3.18 and all boot beautifully. So in my case at least the culprit is 5.4.xx

Is this possibly another i915 issue? If so that is getting fixes in 5.5 that should soon be absorbed into 5.4.

Not for me at least, I am running an NVidia GTX 1660Ti...