0

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!

Richard T
  • 1,206
  • 12
  • 29

2 Answers2

1
Update fstab

One needs to update /etc/fstab files with the proper UUID of the partition

Update crypttab

If your previous partition was encrypted you need to remove the entry from /etc/crypttab

If your new partition is encrypted you need to add the corresponding entry in the /etc/crypttab

Regenerate initramfs

After updating the /etc/fstab and /etc/crypttab file you need to update the initramfs image using dracut.

You could update the dracut image from the dracut emergency shell by running

# dracut --hostonly --regenerate-all --force
References
ksinkar
  • 111
  • 3
  • Thanks for the reply. Though I long-ago fixed this, and it didn't involve either initramfs or the dracut command, I'm glad you posted this as I didn't know about these and I'm sure it'll help others at some point! – Richard T May 08 '23 at 21:53
0

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!

Richard T
  • 1,206
  • 12
  • 29