I updated a fresh install from last week to current cauldron, and now the result of trying to boot is: dracut Warning: Cancelling resume operation. Device not found. dracut Warning: Could not boot dracut Warning: Cancelling resume operation. Device not found. dracut Warning: Could not boot dracut Warning: "/dev/sda5" does not exist Dropping to debug shell dracut:/#
CC: (none) => mageiaAssignee: bugsquad => tmb
I think we'll need more info than that. I'm booting quite happily here.... We'll need to know the results of an lsinitrd and the output from dracut while building the initrd.
(In reply to comment #1) > I think we'll need more info than that. I'm booting quite happily here.... Hmm. No wonder no one else reported this. But literally all I did was urpmi --auto-update for about a week's worth of stuff, and then reboot. > > We'll need to know the results of an lsinitrd and the output from dracut while > building the initrd. Attaching. When this first happened, I was able to boot into single-user mode and try to rebuild the initrd there with -f. That got the same result on reboot. But there is something strange here. To get the following attachments, I booted an rc4.1 partition, mounted the rc5.1 one, and chrooted to it. I first did an lsinitrd of the existing 5.1 initrd, then reran mkinitrd -f, capturing the output, and finally reran lsinitrd on the new 5.1. For comparison, I also ran lsinitrd on the 4.1 initrd. Here's the result: -rw-r--r-- 1 ftg ftg 45730 Jan 29 11:06 lsinitrd4 -rw-r--r-- 1 ftg ftg 56758 Jan 29 11:06 lsinitrd5 -rw-r--r-- 1 ftg ftg 239591 Jan 29 11:12 lsinitrd52 The new lsinitrd52 has 2400+ lines versus 600+ in the original and 490+ in the 4.1. Anyway, on a chance, I retested with the new initrd, but still no joy.
Created attachment 3457 [details] lsinitrd of previously-working rc4.1 kernel
Created attachment 3458 [details] lsinitrd of initially-failing rc5.1 kernel
Created attachment 3459 [details] Output of mkinitrd/dracut rebuilding rc5.1 initrd
Created attachment 3460 [details] lsinitrd of rebuilt rc5.1 initrd
One thought: I still use /dev/sdX notation in my menu.lst because I port a custom one from fresh install to fresh install and don't want to be bothered cut-and-pasting UUIDs. Has something recently happened to break support for specifying root=/dev/sdXx in a GRUB kernel line ? Because that has to be where dracut is getting the /dev/sda5. I leave the UUIDs in the /etc/fstab as MGA generates them.
This may be an anomaly. I notice on my other cauldron systems which were updated but not yet rebooted that the grub menu.lst contains entries for the older kernels, but on the affected system there is only an entry for rc5.1. Makes me wonder if the kernel rpm was completely installed. I was forced to reboot one of the other systems, and this problem didn't occur. I'll cross my fingers and reboot the other.
Well, not so fast. The system where it worked is a desktop system. The one where it originally failed is a laptop. My last cauldron system is a laptop, and its menu.lst also shows only an entry for rc5.1. I'm betting that if I boot that one, it's going to fail as well.
(In reply to comment #9) > I'm betting that if I boot that one, it's going to fail as well. Lost that bet. System booted fine. Also, the menu.lst thing is explained. I assumed that kernel install created a new menu.lst entry for the kernel it was replacing. It doesn't. It creates a specific entry for the kernel being installed. As part of my installs, I replace the generated menu.lst with a custom one of my own, which then "loses" the version-specific entry created for the installed kernel. In the case of this last system, rc4.1 was the installed kernel, so there was no version-specific line there for it, just the one for rc5.1 created by the urpmi run that updated the kernel to rc5.1 Closing this as FM.
Status: NEW => RESOLVEDResolution: (none) => INVALID