[HELP] I Can't Mount EFI Partition While Switching to Systemd-boot

Hi everyone! I really need urgent help because I may have just borked my system entirely. However, I should be in the clear until I reboot it next.

I was trying to get systemd-boot instead of Grub on Fedora 42 using the steps provided here: https://kowalski7cc.xyz/blog/systemd-boot-fedora-32/ however, something weird happened regarding my EFI partition and now, when I try to do sudo mount /efi it returns mount: /efi: can't find UUID=6B92-B74D.

I’m really at a loss at what to do here and I’ve already changed so much that I don’t think that I can go backwards and put Grub back in, nor can I move forwards without the EFI Partition.

I know that I should probably put something to help figure out what exactly is going on, but I’m not sure what, so I’ll just put some outputs. Let me know what else you might need to fix this. Thanks!

user@fedora ~ [1]> lsblk -f
NAME                 FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0                swap   1     zram0  8c480a4a-5b33-4333-99fd-e6bcb933e62a                [SWAP]
nvme0n1
├─nvme0n1p2          ext4   1.0          680b64c5-8efc-4716-a87e-acd0886edc4f
└─nvme0n1p3          crypto 2            6f4c951c-dc95-41c3-84b7-454289e6d7e4
  └─luks-6f4c951c-dc95-41c3-84b7-454289e6d7e4
                     btrfs        fedora b9b32644-500d-43a4-8dad-e6c989226df2    8.6G    98% /home
                                                                                             /
nvme1n1
├─nvme1n1p1          ext4   1.0          87cbde75-867b-49e1-be79-4fa0edb2d801  268.6G    42% /run/media/oeldahan/87cbde75-867b-49e1-be79-4fa0edb2d801
├─nvme1n1p2
├─nvme1n1p3          ntfs                A05A68825A6856D6                      312.5G    24% /run/media/oeldahan/A05A68825A6856D6
└─nvme1n1p4          ntfs                266A5C996A5C6817
user@fedora ~ [1]> sudo fdisk -l
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SKHynix_HFS512GEJ9X115N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B3F25F6B-4799-4502-BB24-E5DF6FE08B05

Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1    2048    3327999   3325952   1.6G EFI System
/dev/nvme0n1p3 3328000 1000214527 996886528 475.4G Linux filesystem


Disk /dev/nvme1n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: KINGSTON SNVS1000G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BB475AE2-F2D1-4B0B-9629-1B39473E3386

Device              Start        End    Sectors   Size Type
/dev/nvme1n1p1       2048 1093363711 1093361664 521.4G Linux filesystem
/dev/nvme1n1p2 1093363712 1093396479      32768    16M Microsoft reserved
/dev/nvme1n1p3 1093396480 1952206847  858810368 409.5G Microsoft basic data
/dev/nvme1n1p4 1952206848 1953521663    1314816   642M Windows recovery environment


Disk /dev/mapper/luks-6f4c951c-dc95-41c3-84b7-454289e6d7e4: 475.34 GiB, 510389125120 bytes, 996853760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/zram0: 8 GiB, 8589934592 bytes, 2097152 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes

Not an answer to your question, but I notice that your EFI partition (/dev/nvme0n1p1) is missing from the output of lsblk -f. That seems weird.

Was it present earlier? (I’m guessing that maybe it was, and that’s how you know its UUID.)

Yeah I’m pretty sure it used to be there before I started this process. I’m not sure what to do now though…

How far had you got in the instructions? Only to the end of the section called “Move ESP mount to /efi” ?

I got to the part where I removed and resized the partitions and then was supposed to mount efi. That’s where I got stuck. I’m guessing that’s where I messed things up.

OK. I’m going to hold off suggesting anything - I’m not 100% sure what has caused this so it would be good to hear from anyone who has a better idea.

1 Like

Did you mean this part?

In my case the system disk is /dev/vda:

sudo parted /dev/vda rm 2
sudo umount /dev/vda1
sudo growpart /dev/vda 1
sudo mount /efi

If you have used a custom partition layout, you will know how to proceed, good luck!

I presume this was meant to remove the partition that holds the /boot and regrow the partition that holds the ESP (efi) partition into the free space.

In general, I would recommend to try this exercise on a system you install in a virtual machine, and repeat until you understand the process. The description in the website, you refer to, seems to involve some dangerous commands which can easily make the system unbootable.

From the fdisk output, it seems that your efi partition may be nvme0n1p1, but the lsblk output does not show that partition at all. In fact it appears that lsblk may still be showing the partition formerly mounted at /boot as nvme0n1p2.

Since the system has not been rebooted I would expect that kind of discrepancy between those tools may occur due to caching the partition tables in the OS. (AFAIK fdisk reads the drive data directly while lsblk uses the known (cached) partitions within the OS)

What happens if you attempt to mount /dev/nvmeon1p1 at /efi? You said you got stuck but did not provide details. Did you create the mount point /efi before attempting to do the mount?
Please show the messages you received.