Update Resulted to Grub Prompt

I recently updated my Fedora and it failed to boot normally. I am currently stuck at the grub prompt. The update includes kernel 6.7.*. The steps that I did at the grub prompt are as follows:

set root=(md/md1)
set gfxpayload=keep
insmod gzio
linux /vmlinuz-6.6.12… root=UUID=“root-uuid” ro rootflags=subvol=root
initrd /initramfs-6.6.12…
boot

The root-uuid is the value I got from "cat (md/md1)/loader/entries/6.6.12.

This takes me to the usual initialization/boot up process then stops. After some time, a lot of “still waiting for following initqueue hooks” message appears then drops me at the root# prompt. My next step should be:

grub2-mkconfig -o /boot/efi/EFI/grub.conf

Unfortunately, I can’t find grub2-mkconfig and /boot.

Please do ask for any information that I might have missed out.

Please help me getting back my desktop up.

1 Like

From Proposed Common Issues to Ask Fedora

That root prompt is probably running in the dracut emergency shell environment. To get to your normal environment, you’ll probably need to mount whatever partition contains your root filesystem to /sysroot (if it is not already there).

This is what each md* contains

This is my fstab

When you get to that root# prompt, you might try the following (I don’t use Btrfs, so I’m not sure about the btrfs command).

# mount -t btrfs -o subvol=rootfs /dev/md2 /sysroot
# exit

Thanks for the suggestion Gregory. Unfortunately, this is what I got

There should be a space between /dev/md2 and /sysroot. But make sure /sysroot isn’t already mounted first.

If the RAID device isn’t auto assembling, it might be this known bug. Unfortunately, the workaround that the last user found for that problem was extremely non-trivial (he had to downgrade a bunch of system packages and regenerate his initramfs). :confused:

Thanks for the correction. This is what I got

What does cat /proc/mdstat show? Can you manually assemble the RAID device?

This is weird. None is detected.

This is looking a lot like that earlier bug. You might have to use a command like the following to discover which partitions are members of which RAID devices.

# blkid /dev/sd* | grep linux_raid_member

Then, a command like the following might work to assemble the devices.

# mdadm --assemble --verbose /dev/md2 <partition1> <partition2> ...

Thanks! They are back!

What would be the next step? I am tempted to reboot but I am not sure if that is correct.

Rebooting at this point would just send you back to square one.

However, these commands might work now:

# mount -t btrfs -o subvol=rootfs /dev/md2 /sysroot
# exit

But nothing is really “fixed” yet. This is just a workaround to get back into your normal system. The blkid command is broken. That must be fixed and your initramfs must be regenerated with the fixed version embedded to prevent this problem from happening every time you reboot.

The only way I’ve heard of to fix the blkid command is to downgrade a bunch of system packages. Unfortunately, that is non-trivial.

The mount command completed successfuly

I think if you “exit” that shell now, your system should continue booting normally.

But again, when you reboot, you’ll be back at square one. :confused:

It’s alive! It’s alive!

Thank you very much! What should be done in order for the fix to be permanent?

@gui1ty is the only person I know to have found a (semi)permanent fix to this bug. Maybe he’ll reply here if he knows more?

I think your old kernels should still work as long as you haven’t regenerated them with the bad blkid command (e.g., by running dracut --regenerate-allnever do this).

Since there is a procedure on how to bring it back up, I’ll do some test for some workarounds. First thing that came to my head is uninstall the latest kernel so that the old kernels may be preserved until a fix is available.

I do hope @gui1ty could chime in.

I’ll update this thread on the outcome of uninstalling the latest kernel.

Thank you very much @glb !

Just an update. Removing kernel 6.7.* did not help. I’ll update this thread with results from future package updates. As of now, suspending my computer instead of shutting down is my workaround.