[Regression] Boot failure on Fedora 43 Kernel 6.18.x with Intel VMD/RAID (dracut timeout)

Ask Fedora
, , , ,
1

Hello Fedora Community,

I am experiencing a critical boot failure after updating to kernel 6.18.x (tested on 6.18.4 and 6.18.5) on Fedora 43 (Rawhide). My system boots perfectly with kernel 6.17.12, so this appears to be a regression in the 6.18 series regarding Intel VMD or MD RAID support.

[System Environment]

  • OS: Fedora 43 (Rawhide)
  • Hardware: Laptop with Intel VMD (Volume Management Device) enabled.
  • Storage: Intel Software RAID (isw_raid_member) / MD RAID configuration (/dev/md126).
  • Filesystem: Btrfs on top of the RAID array.

[Symptoms]
During boot with kernel 6.18.x:

  1. The boot process hangs at dracut-initqueue hooks.
  2. After a long timeout, it drops to the emergency shell.
  3. Error messages:
  • Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks...
  • Warning: /dev/disk/by-uuid/[UUID] does not exist
  • Warning: Not all disks have been found.
  • Warning: You might want to regenerate your initramfs.

[Troubleshooting Steps Taken]
I have tried the following steps, but the issue persists on 6.18.x:

  1. Verified Modules: Checked lsinitrd and confirmed that vmd.ko and mdraid modules are present in the initramfs image.
  2. Forced Driver Load: Regenerated initramfs using:
    dracut --force --add "mdraid" --add-drivers "vmd" --kver 6.18.x
  3. Kernel Parameters: Tried booting with rd.auto=1 and removing specific rd.md.uuid parameters via grubby.
  4. Reinstall: Reinstalled kernel-core and kernel-modules packages.

[Conclusion]
None of the above steps worked. It seems the 6.18 kernel fails to assemble the RAID array or initialize the VMD controller correctly during the initramfs stage, whereas 6.17.12 handles it without issues.

Has anyone else encountered this issue with Intel VMD/RAID on Rawhide kernel 6.18? Is there a specific workaround or a known bug report for this?

Thank you for your help.

2

I wonder if it is really the kernel or if it could be dracut? Has the working initramfs been regenerated since dracut was last updated?

It reminds me of this bug which ended up being due to this PR. It looks like there might have been another change to that 59-persistent-storage-dm.rules file in dracut recently (8 months ago, but I’m not sure how long it might have taken that to propagate to Fedora Linux).

1 Like
3

Rawhide is the unstable development version of fedora. As such users should always anticipate instability and problems. Support for rawhide is not done on this forum.

If you wish a stable version then I suggest that you revert to one of the currently supported and released versions (either 42 or 43).

Fedora 43 has kernel 6.18.5 already and is very stable for me.

4

To @glb: That is a very sharp insight. To answer your question: No, I have not regenerated the initramfs for the working kernel (6.17.12) recently. I am currently using that kernel to access my system, so I am afraid to regenerate its initramfs in case the current version of dracut is indeed the culprit and breaks my only working boot option.

If dracut rules regarding dm-raid or vmd have changed recently, that would explain why the new kernel images (generated post-update) are failing to assemble the RAID array.

To @computersavvy: Thanks for the confirmation. Since 6.18.5 works for you, it confirms this is an issue specific to the combination of Intel VMD + isw_raid_member on the current Rawhide stack.

Decision: Since this is my main laptop, I cannot risk breaking the 6.17 kernel by testing dracut regeneration. I have version-locked the kernel to 6.17 for now and will plan to migrate to Fedora 41 Workstation (Stable) soon to avoid these bleeding-edge regressions.

Thanks for your help!

5

Confirmed: My local module-setup.sh contains the aggressive sed logic to strip incremental assembly rules, which likely breaks VMD detection.

6

Just so you are aware, F41 has now been EOL for about 2 months and F43 is the most recent stable version.

7

Correction: My System is STABLE, not Rawhide.

I apologize for the confusion in my initial report. I double-checked my /etc/os-release and realized I am running the Fedora 43 Stable Release (RELEASE_TYPE=stable), NOT Rawhide.

PlaintextPRETTY_NAME="Fedora Linux 43 (KDE Plasma Desktop Edition)" RELEASE_TYPE=stable

Significance: This means the broken Kernel 6.18 update (and the incompatible dracut logic) has been pushed to the Stable channel. This is not just a Rawhide experiment gone wrong; it is a critical regression affecting production systems using Intel VMD/RAID.

Please prioritize this issue as it renders the system unbootable for standard users with this hardware configuration.

1 Like
8

This means you probably should open a bug report at redhat.bugzilla.com and post your details there. The bug report will normally be pushed upstream to the kernel developers. You can mark it critical if you choose

I don’t think it is related to mdraid since I am using mdraid on 2 different systems and have had no issues whatsoever.