Dracut -initque 45 seconds on startup plz help

yesterday suddenlyi started getting long queue times.


 systemd-analyze blame
44.850s dracut-initqueue.service
 9.275s NetworkManager-wait-online.service

could annyone provide me with assistance ?

Same problem persists after my system got hacked and i did a clean reinstall

Is there anything in the dmesg logs? Maybe try something like this:

dmesg | grep dracut-initqueue

BTW, it looks like there is an update for dracut working its way through the build system. You might be hitting a known bug that is actively being patched.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/R74R2UQSXWPDLRETJUOLYAZ4FT6USEPT/

~
❯ dmesg | grep dracut-initqueue
[   46.411195] audit: type=1130 audit(1664291082.373:19): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

hmm i don’t know how to proceed.

It doesn’t appear that that was very informative.

You might also try journalctl -b | grep dracut-initque. But looking at that email notification that I shared a link to earlier, it appears that the logging for dracut might be pretty minimal unless you add rd.debug to the kernel command line.

Do you have an encrypted root filesystem? It looks like that is the main thing the updated dracut package is trying to fix. Although, the email says “does contain a lot of fixes”. So maybe it would be worth trying it just to see if it fixes your problem anyway.

Did anyone find a solution for this? Facing the same issue in F36 with kernel 5.19.14

It might be worth checking to see if there is anything in the “initqueue” that shouldn’t be. FWIW, here is what mine looks like.

[/root]# systemd-analyze blame | grep dracut
  49ms dracut-shutdown.service
  48ms dracut-cmdline.service
  41ms dracut-pre-pivot.service
  38ms dracut-mount.service
  25ms dracut-pre-mount.service
  23ms dracut-initqueue.service
  21ms dracut-pre-udev.service
[/root]# lsinitrd | grep dracut/hooks
drwxr-xr-x  15 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/cleanup
-rwxr-xr-x   1 root     root          308 Jun 19 17:35 usr/lib/dracut/hooks/cleanup/99-memstrack-report.sh
-rwxr-xr-x   1 root     root          264 Sep 26 09:47 usr/lib/dracut/hooks/cleanup/99-zfs-needshutdown.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/cmdline
-rwxr-xr-x   1 root     root          918 Jun 19 17:35 usr/lib/dracut/hooks/cmdline/91-dhcp-root.sh
-rwxr-xr-x   1 root     root          969 Sep 26 09:47 usr/lib/dracut/hooks/cmdline/95-parse-zfs.sh
-rwxr-xr-x   1 root     root         1083 Jun 19 17:35 usr/lib/dracut/hooks/cmdline/99-nm-config.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/emergency
-rwxr-xr-x   1 root     root           56 Jun 19 17:35 usr/lib/dracut/hooks/emergency/50-plymouth-emergency.sh
drwxr-xr-x   6 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/initqueue
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/initqueue/finished
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/initqueue/online
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/initqueue/settled
-rwxr-xr-x   1 root     root         2219 Jun 19 17:35 usr/lib/dracut/hooks/initqueue/settled/99-nm-run.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/initqueue/timeout
-rwxr-xr-x   1 root     root          463 Jun 19 17:35 usr/lib/dracut/hooks/initqueue/timeout/99-rootfallback.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/mount
-rwxr-xr-x   1 root     root         3369 Sep 26 09:47 usr/lib/dracut/hooks/mount/98-mount-zfs.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/netroot
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/pre-mount
-rwxr-xr-x   1 root     root         2215 Sep 26 09:47 usr/lib/dracut/hooks/pre-mount/90-zfs-load-key.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/pre-pivot
-rwxr-xr-x   1 root     root         9387 Jun 19 17:35 usr/lib/dracut/hooks/pre-pivot/85-write-ifcfg.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/pre-shutdown
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/pre-trigger
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/pre-udev
-rwxr-xr-x   1 root     root         1148 Jun 19 17:35 usr/lib/dracut/hooks/pre-udev/50-ifname-genrules.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/shutdown
-rwxr-xr-x   1 root     root          461 Sep 26 09:47 usr/lib/dracut/hooks/shutdown/20-export-zfs.sh
drwxr-xr-x   2 root     root            0 Sep 26 09:47 usr/lib/dracut/hooks/shutdown-emergency

Did not find anything that’s not supposed to be there, but did find some units missing as compared to yours like

dracut-mount.service
dracut-pre-mount.service

here’s the results

sudo systemd-analyze blame | grep dracut
2min 52ms dracut-initqueue.service
  30.060s dracut-pre-pivot.service
    380ms dracut-shutdown.service
     79ms dracut-cmdline.service
     40ms dracut-pre-udev.service
sudo lsinitrd | grep dracut/hooks
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /cleanup
-rwxr-xr-x   1 root     root          308 Jun 20 04:05 usr/lib/dracut/hook /cleanup/99-memstrack-report.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /cmdline
-rwxr-xr-x   1 root     root          918 Jun 20 04:05 usr/lib/dracut/hook /cmdline/91-dhcp-root.sh
-rwxr-xr-x   1 root     root         1083 Jun 20 04:05 usr/lib/dracut/hook /cmdline/99-nm-config.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /emergency
-rwxr-xr-x   1 root     root           56 Jun 20 04:05 usr/lib/dracut/hook /emergency/50-plymouth-emergency.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /initqueue
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /initqueue/finished
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /initqueue/online
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /initqueue/settled
-rwxr-xr-x   1 root     root         2219 Jun 20 04:05 usr/lib/dracut/hook /initqueue/settled/99-nm-run.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /initqueue/timeout
-rwxr-xr-x   1 root     root          463 Jun 20 04:05 usr/lib/dracut/hook /initqueue/timeout/99-rootfallback.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /mount
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /netroot
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /pre-mount
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /pre-pivot
-rwxr-xr-x   1 root     root         9387 Jun 20 04:05 usr/lib/dracut/hook /pre-pivot/85-write-ifcfg.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /pre-shutdown
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /pre-trigger
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /pre-udev
-rwxr-xr-x   1 root     root         1148 Jun 20 04:05 usr/lib/dracut/hook /pre-udev/50-ifname-genrules.sh
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /shutdown
drwxr-xr-x   1 root     root            0 Sep 26 20:17 usr/lib/dracut/hook /shutdown-emergency

Yeah, ignore that. Mine is different because it is configured with a zfs root file system. What’s important is that you don’t have anything else.

It looks like your system is also spending some extra time in the pre-pivot stage. But the only script in that stage is /pre-pivot/85-write-ifcfg.sh. I think that is for managing networking during the early boot stages. That sort of thing is often done when booting off a network drive (the operating system is stored on a remote server rather than on the local hard drive). Are you doing anything like that? If so, that sort of delay might be normal. I’m not sure.

I think my problem got fixed after the last Dracut update.
As its now on 0.5 secs

I Wil leave it open for the other person dude as my update happened i think 2 days ago.

I actually am booting from my SSD and not a network drive.
On a rare occasions the pc booted normally without any delay. I did capture some logs there.But after that I had no luck.

7.532s plymouth-quit-wait.service
6.609s NetworkManager-wait-online.service
3.529s dracut-initqueue.service
2.724s upower.service
1.789s lvm2-monitor.service
1.753s initrd-switch-root.service
1.483s firewalld.service
1.361s fwupd.service
 986ms systemd-resolved.service
 975ms polkit.service
 961ms power-profiles-daemon.service
 956ms udisks2.service
 914ms avahi-daemon.service
 887ms accounts-daemon.service
 846ms systemd-rfkill.service
 822ms var-lib-nfs-rpc_pipefs.mount
 783ms systemd-oomd.service
 715ms rtkit-daemon.service
 651ms switcheroo-control.service
 638ms systemd-logind.service
 567ms systemd-machined.service
 529ms ModemManager.service
 518ms plymouth-switch-root.service
 498ms thermald.service
 488ms abrtd.service
 454ms systemd-journal-flush.service
 388ms dracut-shutdown.service
 382ms bluetooth.service
 366ms packagekit.service
 365ms livesys.service
 359ms cups.service
 310ms user@1000.service
 290ms gssproxy.service
 288ms systemd-udevd.service
 247ms chronyd.service
 238ms systemd-tmpfiles-setup.service
 231ms auditd.service
 218ms systemd-udev-trigger.service
 204ms initrd-parse-etc.service
 185ms systemd-userdbd.service
 172ms dbus-broker.service
 161ms sssd-kcm.service
 152ms systemd-vconsole-setup.service
 136ms systemd-tmpfiles-setup-dev.service
 135ms systemd-fsck@dev-disk-by\x2duuid-3025a390\x2db892\x2d4c0a\x2dba7c\x2d1207aeacb0f5.service
 135ms systemd-fsck@dev-disk-by\x2duuid-8DEA\x2d4D74.service
 133ms import-state.service
 128ms home.mount
 125ms virtqemud.service
 120ms dev-zram0.swap
  99ms systemd-zram-setup@zram0.service
  96ms NetworkManager.service
  92ms systemd-boot-update.service
  87ms boot-efi.mount
  84ms systemd-sysctl.service
  80ms nfs-convert.service
  79ms modprobe@drm.service
  79ms kmod-static-nodes.service
  78ms dev-hugepages.mount
  76ms dev-mqueue.mount
  75ms systemd-remount-fs.service
  75ms dracut-cmdline.service
  74ms systemd-network-generator.service
  73ms sys-kernel-debug.mount
  72ms colord.service
  72ms systemd-modules-load.service
  71ms sys-kernel-tracing.mount
  71ms systemd-random-seed.service
  69ms livesys-late.service
  67ms initrd-cleanup.service
  63ms boot.mount
  60ms dracut-pre-pivot.service
  58ms systemd-journald.service
  56ms systemd-update-utmp.service
  49ms plymouth-read-write.service
  46ms uresourced.service
  46ms user-runtime-dir@1000.service
  39ms systemd-sysusers.service
  39ms tmp.mount
  37ms dracut-pre-udev.service
  35ms systemd-fsck-root.service
  31ms initrd-udevadm-cleanup-db.service
  31ms sys-fs-fuse-connections.mount
  30ms systemd-user-sessions.service
  27ms sys-kernel-config.mount
  26ms rpc-statd-notify.service
  23ms wpa_supplicant.service
  19ms plymouth-start.service
  19ms gdm.service
  17ms systemd-backlight@backlight:amdgpu_bl0.service
  14ms systemd-update-utmp-runlevel.service
   6ms modprobe@configfs.service
   5ms modprobe@fuse.service

It would be a workaround rather than a fix. But the dracut man page provides the following option.

$ man dracut | grep -A 5 'Omitting dracut Modules'
   Omitting dracut Modules
       Sometimes you don’t want a dracut module to be included for reasons of speed, size or functionality. To do this, either specify the omit_dracutmodules variable in
       the dracut.conf or /etc/dracut.conf.d/myconf.conf configuration file (see dracut.conf(5)), or use the -o or --omit option on the command line:

           # dracut -o "multipath lvm" no-multipath-lvm.img

From the output that you’ve provided so far, it looks like the /initqueue/settled/99-nm-run.sh and /pre-pivot/85-write-ifcfg.sh are likely the source of the delay. Those scripts both appear to be part of the dracut-network package.

$ find /usr/lib/dracut/modules.d -name '*nm-run.sh'
/usr/lib/dracut/modules.d/35network-manager/nm-run.sh
$ find /usr/lib/dracut/modules.d -name '*write-ifcfg.sh'
/usr/lib/dracut/modules.d/45ifcfg/write-ifcfg.sh
$ rpm -qf /usr/lib/dracut/modules.d/35network-manager/nm-run.sh
dracut-network-057-3.fc36.x86_64
$ rpm -qf /usr/lib/dracut/modules.d/45ifcfg/write-ifcfg.sh
dracut-network-057-3.fc36.x86_64

If you don’t think you need networking during early boot, one option/workaround would be to disable the network and ifcfg modules in dracut.

$ sudo lsinitrd | grep nm-run.sh
-rwxr-xr-x   1 root     root         2219 Jun 19 17:35 usr/lib/dracut/hooks/initqueue/settled/99-nm-run.sh
$ sudo dracut -f -o 'network ifcfg'
$ sudo lsinitrd | grep nm-run.sh
$ 

It would probably be wise to verify that you have a working kernel+initramfs to fallback to before rebuilding your current initramfs with the above commands. It should be easy to pick a different kernel at boot time. :slightly_smiling_face: Also, beware that the dracut and lsinitrd commands work on the currently-booted kernel version if no version number is explicitly provided (so you will need to reboot back to your default kernel before running the above commands).

If you find that omitting the network and ifcfg modules is an acceptable workaround for your situation, you can make that change permanent by creating a .conf file under /etc/dracut.conf.d with the following contents.

omit_dracutmodules+=" network ifcfg "

* note that the leading and trailing spaces within the double quotes are important

Tried this, but the system failed to boot.

I’m quite sure that dracut should work without networking support. Unless maybe you have something like clevis installed with network-based unlocking? But if you are doing that, then I don’t think there would be any way around the slow boot time.

I don’t have network-based unlocking setup.

I tried to reinstall F37 but the problem still persisted even in a fresh install.

Looking at the logs I see this:

[  538.977691] ata2: EH pending after 5 tries, giving up
[  539.462946] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  539.470479] ata2.00: configured for UDMA/100
[  539.942981] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  539.949292] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x100)
[  539.949303] ata2.00: revalidation failed (errno=-5)
[  545.495132] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  545.502637] ata2.00: configured for UDMA/100
[  545.975169] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  545.982658] ata2.00: configured for UDMA/100
[  546.455242] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  546.462773] ata2.00: configured for UDMA/100
[  546.935178] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  546.942708] ata2.00: configured for UDMA/100
[  546.945798] ata2: EH pending after 5 tries, giving up

These logs keep on recurring, which I guess is related to the SSD?

Any idea how to move forward from here?

Thank you for your time.

PS: I do have a CD reader in my pc and there is a USB 2.0 port which is faulty. (Don’t know how it’ll help though)

Edit: Looking at the output of a shell script

for i in `grep -l Gbps /sys/class/ata_link/*/sata_spd`; do
 echo Link "${i%/*}" Speed `cat $i`
 cat "${i%/*}"/device/dev*/ata_device/dev*/id | perl -nE 's/([0-9a-f]{2})/print chr hex $1/gie' | echo "    " Device `strings` | cut -f 1-3
done

I found this:

Link /sys/class/ata_link/link1 Speed 6.0 Gbps
     Device 22011Y803988 UF870400WDC WDS240G2G0A-00JH30 4k} A#4i
Link /sys/class/ata_link/link2 Speed 1.5 Gbps
     Device M2HH8HN3310 A1C2 HL-DT-ST DVD+/-RW GU90N

So it is the DVD device in fault here, I will try to dismount the DVD drive and update later.

Tried disconnecting the dvd drive and bamm, it worked. Its booting fast now. Yay