It has failed to boot fedora since ESP was changed

I have backed up all the files into ESP, the folders named EFI and System, and a file named mach_kernel.

I have just formatted the ESP, whose UUID must be changed, and copy the backup into it.

There has been the grub apearing with the LOGO of fedora apearing then.

But it has failed to boot fedora since the ESP was not as same as it before though all the files into ESP have been being as same as them before.

Help me!

Who could tell me how to boot successfully without re-installation?

Are you getting far enough in the boot process that it gets to an emergency prompt when it fails?

Did you update /etc/fstab with the new UUID for the ESP?

Yes, I am.
No, I didn’t.
I can read btrfs by liveCD of fedora.
I don’t know how to do.

Why can it boot Windows, Mac, Android x86, ChromeOS successfully by an ESP with new UUID?

Why does fedora mount ESP with only UUID?

It could have mounted ESP where shim.efi is.

It is hard to say with the amount of information here but my guess would be that it is booting fine.

However, when it reaches the part of the boot process where it tries to mount the ESP partition it fails which blocks further progress.

Mounting by UUID is the most broadly used method, since device names and labels can change.

It seems likely that since the UUID for /boot/efi has changed that you may need to generate a new initramfs image.
Boot to live media, mount the entire installed filesystem properly under /mnt (this includes /, /boot, /boot/efi, /home, and any other system filesystems you may have such as /var, etc) so the full tree is mounted.
Then properly do a chroot to /mnt and use dracut --force 5.17.2-300.fc36.x86_64 to regenerate the image with that kernel version.

I have that version kernel for fedora 36 since I am fully updated but your latest kernel may be different.

image

How about mounting the partition as /boot/efi, whose BDB(DBR) Label has been named ESP.
It is because the Normal Label and UUID could be changed, too;
FAT16 and FAT32 have BDB(DBR) Label, NTFS, btrfs, ext4 and so on have no.

Or disable auto-mount ESP just like Windows, Mac, Android x86, ChromeOS and so on.
If need be, users could mount ESP by gnome disk.

Could I input
sudo dnf update
sudo dnf upgrade
using running liveCD?
Files for booting will be updated, too.

You can do whatever you want on your system.

UUID is the default but if you would prefer to mount by label or not mount the ESP that is certainly your choice.

If you are asking about changing the default behaviour than I have a couple of thoughts.

  • I think that would be a solution to something that isn’t really a problem in the first place. Changing the UUID of a partition isn’t something that is commonly done.
  • This isn’t the place to make such a proposal.

So could it be a coming feature ???
Disable to auto-mount ESP or auto-mount the partition as /boot/efi , whose BDB(DBR) Label has been named ESP

While I personally think that would be terrible change, it isn’t up to me so my opinion doesn’t really matter in this case. :sweat_smile:

Either way, this forum isn’t the correct place to propose such a change.

In my earlier post I suggested using dracut to fix the mount parameters to match the initramfs image so the esp would mount properly.

I neglected to mention that you could also change the UUID of the partition to match the original and that should allow mounting it properly as well.

The UUID can be changed with fdisk, gdisk, parted, gparted, and many other partition management tools.

But I haven’t noted the UUID before.

@1457384613fdr, did you try editing /etc/fstab and putting the correct UUID in it?

Is that even needed? Doesn’t the initrd mount the root filesystem and then systemd reads /etc/fstab?

I honestly do not know in detail what is in the initramfs image.

I do know that it is an image of the system as it was when the relevant kernel was installed, and thus may depend upon the specific UUIDs of the partitions as well. It likely has a copy of the /etc/fstab file in that image as it was when the image was created and may depend upon that particular UUID to mount /boot/efi properly.

I don’t know for certain that is the case but logic leads me to that as a possibility.