Description of problem: Any kernel with an initrd made with dracut doesn't boot. It says it cannot find the root device, while a ls -l actually shows the device in /dev. Only guess is perhaps it is due to the block: before the root device. Maybe it searches that path? Version-Release number of selected component (if applicable): 014-9.mga2 How reproducible: Try to boot latest kernel
This is just kernel command line issues. Not tracked it down yet, but just remove the resume= bit from the command line and it should boot fine.
Created attachment 1313 [details] Error message by dracut If you want me to try some commands, tell me.
oh.. you already responded :) damn quick. will try
Actually one thing you could try: a) Remove the whole resume= argument and check that it then boots. b) Double check what the UUID in the resume= argument says and compare it to the output from the blkid command. It should match your swap, but I suspect it does not.... changing it to match that of your swap partition should then make it boot. The primary problem I noticed is that the kernel command line UUID simply didn't match my swap space UUID and thus it was always waiting for a device that just doesn't exist. I think this is valid, but it should just continue with regular boot if the swap partition can not be found rather than bail hard!
I removed the whole resume= stuff and it boots! The UUID in the resume is 327c5e86-2993-4f0f-baba-58462e3afa21. I don't have such an UUID partition (nothing in /dev/disk/by-uuid, nor /etc/fstab). Pretty sure that is some old disk (have switched hard drives). So somewhat of a self-created problem. But would be nice if something would catch this (either fix the resume=, or warn me).
Yeah, others have reported this as well. I even ran into it myself while generally doing bad things on my VM... so it does need to be fixed. I know how to do it, so it should be easy enough :)
OK, so this should be fixed in latest dracut (10.mga2). I also fixed the bogus error message about the root device not being found. There are still a bunch of warning spat out due to udevadm command syntax that need to be fixed, but the general principle of waiting for the device, timing out, issuing a warning, removing the wait for device and then continuing with normal boot works fine. Will submit upstream.
Status: NEW => RESOLVEDResolution: (none) => FIXED