Heya, I’ve spent the last few hours digging through the mountain of old posts about dracut and initrd causing slow boot times, but none of the solutions have worked for me with Fedora SilverBlue 36 (fedora:fedora/36/x86_64/silverblue).
Like the older posts, it seems that dracut-initqueue is causing the issue:
All to no avail. I have also checked my kernel cmdline arguments for resume=, with no luck.
I initially thought this might be a systemd unit not starting, since the boot times I was getting were just a touch above 2 minutes, and iirc some systemd units abort if not successful after two minutes, but that doesn’t seem to be the case.
I’m more than happy to provide any and all information required to fix this, and open an issue if necessary, I didn’t wanna do that initially though, in case I’ve done something wrong.
I was always told to look for systemd-analyze critical-chain instead of reading blame output because, “processes run concurrently” and blame doesn’t represent that. I hope I didn’t get it wrong, am I?!
Anyway, I used the command in the post, and I see this:
⟹ systemd-analyze blame | head -n1
17.239s dnf-makecache.service
It could. Attempting to configure a device is repeated several times until it times out.
The commands given can help, as can dmesg and looking at the logs with journalctl. The dmesg entries are given in seconds since power on (with 6 decimal accuracy) so that may offer some clues.
I took a look at dmesg, and in it looks like the messages related to dracut are all in the two or two and a half second range, except for 2 messages – the messages that indicate that dracut-initqueue and dracut-pre-mount have exited successfully, at around eighty seconds. In between those messages seem to be unrelated information related to GPU initialization. I’ve uploaded part of the dmesg output to pastebin.
More or less the same story for journalctl, just the service start/stop messages and those GPU initialization messages I mentioned.
It genuinely looks like dracut is just sitting there doing nothing for a minute and a half…
[ 16.457037] usb 3-1: device descriptor read/64, error -110
[ 32.329040] usb 3-1: device descriptor read/64, error -110
[ 32.545009] usb 3-1: new full-speed USB device number 3 using xhci_hcd
[ 48.201063] usb 3-1: device descriptor read/64, error -110
[ 64.073035] usb 3-1: device descriptor read/64, error -110
[ 64.175055] usb usb3-port1: attempt power cycle
[ 64.555009] usb 3-1: new full-speed USB device number 4 using xhci_hcd
[ 69.591029] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[ 75.223033] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[ 75.431008] usb 3-1: device not accepting address 4, error -62
[ 75.545007] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[ 80.855032] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[ 86.487049] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[ 86.695006] usb 3-1: device not accepting address 5, error -62
[ 86.695051] usb usb3-port1: unable to enumerate USB device
86-16 Sec. = 70Sec. = 1Min 10Sec. try to connect to USB 3-1
You loose quite a lot of time with your broken USB.
Is it a USB with the cable to the front panel who is not working?
Or is it an USB port soldered to the motherboard?
If it is the first one, you can try to take the cable off on the motherboard and see if this changes something.
Just got the chance to try this, and the removable USB header doesn’t seem to be the problem, those errors still appear. Its possible that my motherboard is faulty and needs to be replaced, in all honesty, but I’m not able to replace it at the moment, so I guess I’ll just live with it.
Unless you have any other ideas, I think I’m gonna assume its an issue with my hardware.
Since the attempts to configure the USB device seem to take almost 90 seconds I think that it is likely hardware.
I notice that the problem is with USB 3-1 and that USB 3-2 seems to have a 4-port hub attached. What happens if you disconnect that 4 port hub?
One channel on a controller can interfere with another channel.