Dracut Emergency Shell – How to Fix System Boot Issues After Disk Partition Change

bootdracutuuid

Background

I had a new system that I'd spent a lot of time configuring the software on to perform all manner of services and then discovered the drive was potentially flaky. So I decided to replace the disk, keeping the contents for the new disk.

The system disk also had a problem booting into correct kernel that I couldn't seem to fix (I followed all the grub directions but it just woudn't boot the right kernel by default, only if you manually chose the right one). So, I figured the best way was to simply do a new installation of Fedora Server onto the new disk and that would fix the boot problem along the way.

What Happened

The new disk was a lot bigger, so I partitioned it a little differently during the installation process. I then removed the drive and put both the new and the old system disk into another server I had nearby. Out of an abundance of caution, I kept the fstab from the new system disk, knowing it had the partition UUIDs.

There are many ways to move things around and I decided I wanted a clean root partition on the new system disk. I figured dd might be able to do this but I'm used to using it where the partitions are the same size and was a little unsure, so instead I just reformatted the root partition ("/") with gparted. I then moved the files over using normal OS tools. I then cut and pasted the UUID stuff from the new installation and inserted it into the very-non-stock fstab from the server I was fixing.

That went fine.

I then attempted to boot the system. It posted, then got to the grub boot loader, it automatically selected the right kernel and away it went! … Until it didn't!

It got to "show Plymouth Boot Screen" or something like that, paused, and then gave a lot of timeout warnings from something calling itself dracut. From here, I took a screen shot with my phone. It says:

Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-uuid/<a uuid> does not exist
Generating "/run/initramfs/rdsosreport.txt"

followed by a suggestion to use journalctl and perhaps to save the rdsosreport.txt for bug reporting.

ACK! What to do? I searched high and low for this the Warning [...] does not exist and dracut emergency shell stuff cited above. Nada!

Best Answer

The message:

Warning: /dev/disk/by-uuid/<uuid> does not exist

is a major clue.

It turns out that the root partition's UUID is stored in two places in the grub2 portion of the modern Fedora Server's /boot partition. But in this scenario, there are actually three UUID problems.

The reformatting of the root partition ("/") actually changed the UUID. So, the new UUID has to be first discovered and then put into the right locations. There are many ways to find UUIDs but one command-line tool to do this is blkid - as in this example:

# blkid
/dev/sda1: UUID="64bbac09-1a12-4bea-8873-212ffb56f2a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="8a09913a-fdb2-42a0-98e3-6b89e16374d2"

Note that for each partition, there are two UUIDs shown by this tool; you want the first of these. Note also that non-privileged users cannot run blkid.

Here are the three places the root partition's UUID needs to be:

  1. In /etc/fstab on the line where the root partition mount is described, and;
  2. In /boot/grub2.cfg on the line setting kernel options. The fast way to find it is to look for the former UUID if you still have it. Or look for "set kernelopts="root=UUID=", and;
  3. In /boot/grub2/grubenv on a line that looks similar to the line cited in the /boot/grub2.cfg file. Look for: kernelopts=root=UUID=

Remember to only change out the one UUID that is new and leave everything else as-was. Maybe make a backup of the file before editing, just in case!

Related Topic