Dracut tries to boot with incorrect disk UUID

[nickdegraeve]

I need some help getting my system to boot again.

The problems started when I tried out the newest SteamOS. I had overwritten my GRUB menu with the one that came with SteamOS.
I removed the SteamOS partitions again and wanted to restore my original GRUB menu by booting in Mageia 4.1 Live DVD. But with MCC --> Boot --> Set up boot system nothing seems to be saved to disk.
So I used the Windows recovery to reset the MBR. Next I booted once more in Mageia 4.1 Live DVD and did an install using my existing partitions. Now I got my menu back.

Unfortunately, when I try to boot in Mageia, Dracut crashes with

Code: Select all

dracut Warning: Could not boot.
dracut Warning: /dev/disk/by-uuid/80b9c7f2-e6f3-41c4-827c-300085565d7f does not exist

Indeed the disk with UUID 80b9c7f2-e6f3-41c4-827c-300085565d7f doesn't exist but I don't know where it gets that ID.

My /boot/grub/menu.lst doesn't mention it at all:

Code: Select all

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,4)/gfxmenu
default 0

title linux
kernel (hd0,4)/vmlinuz BOOT_IMAGE=linux root=UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b  nokmsboot splash quiet resume=UUID=3f535cdc-fe16-4a4e-9a6e-36b54b819672 vga=788
root (hd0,4)
initrd /initrd.img

title linux-nonfb
kernel (hd0,4)/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b  nokmsboot resume=UUID=3f535cdc-fe16-4a4e-9a6e-36b54b819672
root (hd0,4)
initrd /initrd.img

title failsafe
kernel (hd0,4)/vmlinuz BOOT_IMAGE=failsafe root=UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b  nokmsboot failsafe
root (hd0,4)
initrd /initrd.img

title windows
root (hd0,0)
makeactive
chainloader +1


None of my disks have that ID:

Code: Select all

[root@localhost ~]# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Feb 15 13:24 2014-06-06-13-07-41-00 -> ../../sdd4
lrwxrwxrwx 1 root root 10 Feb 15 13:24 38706DED706DB274 -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb 15 13:24 3f535cdc-fe16-4a4e-9a6e-36b54b819672 -> ../../sda6
lrwxrwxrwx 1 root root 10 Feb 15 13:24 46b5e871-ae62-4e37-86ae-1503cfd79b0b -> ../../sda7
lrwxrwxrwx 1 root root 10 Feb 15 13:24 5f4d7cf4-fe77-468b-a9ac-c5e77f56509e -> ../../sda8
lrwxrwxrwx 1 root root 10 Feb 15 13:24 799ED12B787B862B -> ../../sdd2
lrwxrwxrwx 1 root root 10 Feb 15 13:24 9F18-707E -> ../../sdd1
lrwxrwxrwx 1 root root 10 Feb 15 13:24 a5a63586-87c3-4c8d-b08d-11cbe22e6b9b -> ../../sda5
lrwxrwxrwx 1 root root 10 Feb 15 13:24 E0DCE989DCE959F4 -> ../../sda2


I attached the complete report file for more details.

Any ideas?

[unklar]

Hanging on the kernel line nofail
If that does not work then a live CD, the UUID correct for the swap in fstab

[nickdegraeve]

Sorry, you reply is a bit cryptic.

Anyway I've got some extra info.

First of all, it seems the menu that is displayed during boot isn't menu.lst but menu.lst.old. Why?
And this is it:

Code: Select all

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,4)/gfxmenu
default 0

title Mageia
kernel /boot/vmlinuz BOOT_IMAGE=linux root=UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b  nokmsboot splash quiet resume=UUID=3f535cdc-fe16-4a4e-9a6e-36b54b819672 vga=788
root (hd0,4)
initrd /initrd.img

title Mageia (failsafe)
kernel (hd0,4)/vmlinuz BOOT_IMAGE=failsafe root=UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b  nokmsboot failsafe
root (hd0,4)
initrd initrd.img

title Windows 7
root (hd0,0)
makeactive
chainloader +1


It isn't much different than the one I posted before: the UUIDs are the same and correct.

Just to be clear, they are correct in /etc/fstab too:

Code: Select all

# Entry for /dev/sda7 :
UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b / ext4 defaults 1 1
# Entry for /dev/sda5 :
UUID=a5a63586-87c3-4c8d-b08d-11cbe22e6b9b /boot ext4 defaults 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda6 :
UUID=3f535cdc-fe16-4a4e-9a6e-36b54b819672 swap swap defaults 0 0


I also booted with the rd.debug kernel parameter and now I got lots more output in the attached file rdsosreport-debug.txt.
The strange UUID appears lots of times, but I still can't figure out from where it comes.

[doktor5000]

Please search for dracut and initrd here in the forums. That UUID is buried in the initrd, you may need to regenerate that, there are lots of threads about this issue sadly.

[unklar]

You need to know yourself what you have created in the past!

Code: Select all

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,4)/gfxmenu
default 0

title linux
kernel (hd0,4)/vmlinuz BOOT_...


Code: Select all

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,4)/gfxmenu
default 0

title Mageia
kernel /boot/vmlinuz BOOT_...

# Entry for /dev/sda7 :
UUID=46b5e871-ae62-4e37-86ae-1503cfd79b0b / ext4 defaults 1 1
# Entry for /dev/sda5 :
UUID=a5a63586-87c3-4c8d-b08d-11cbe22e6b9b /boot ext4 defaults 1 2

If the kernel now from sda7 or sda5 boot?

[jond]

Don't know if this is considered resurrecting an old thread.(if so, sorry) But since its not marked solved and still on the first page:

Is this boot with bad UUID issue addressed in version 5 of Mageia?

I ran into this problem, and searched around and followed the steps in the link below (translated) and I think it's OK now:
http://www.mageialinux-online.org/wiki/ ... d-not-boot

This fix is a royal pain in the ...
Most other major distros (Ubuntu, Fedora, even Arch) handle a reformatted swap partition with new UUID just fine, they just simply don't use it and continue to boot. Then you just update the fstab and turn swap back on and all is well.

Not like the complete abort of the boot process as in Mageia 4 requiring that long complicated fix.

[doktor5000]

It should get fixed, it is still marked as a release blocker for Mageia 5.
You can watch the status at https://bugs.mageia.org/show_bug.cgi?id=12305