[HELP] /efi fails to mount

Context:

I updated my system last night (EndeavourOS) and it looks like the kernal didn’t update correctly. When I restarted the system and entered my password for the encrypted drive, I get an error:


<span style="color:#323232;">[FAILED] Failed to mount /efi
</span><span style="color:#323232;">See 'systemctl status efi.mount` for details.
</span>

I can’t remember the commands I used last night but I was able to check the version of the kernel I am using currently - uname -r I believe - and what is installed. There was a difference in versions.

Trying to fix the problem:

I attempted to chroot into the system via a live USB - tutourial, arch bbs & arch wiki.

However, when trying to mount the drive (/dev/sda2) I get an error message: mount: /rescue: unknown filesystem type ‘crypto_LIKS’. I tried using cryptsetup luksOpen’ and ‘udisksctl unlock -b’ but both return a similar error saying it is not an encrypted device. See fdisk -l results below:


<span style="color:#323232;">[liveuser@eos-2024.04.20 ~]$ sudo fdisk -l
</span><span style="color:#323232;">Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
</span><span style="color:#323232;">Disk model: TOSHIBA KSG60ZMV
</span><span style="color:#323232;">Units: sectors of 1 * 512 = 512 bytes
</span><span style="color:#323232;">Sector size (logical/physical): 512 bytes / 4096 bytes
</span><span style="color:#323232;">I/O size (minimum/optimal): 4096 bytes / 4096 bytes
</span><span style="color:#323232;">Disklabel type: gpt
</span><span style="color:#323232;">Disk identifier: FC41E181-15E3-4444-8240-E68D52AFD07E
</span><span style="color:#323232;"> 
</span><span style="color:#323232;">Device         Start       End   Sectors   Size Type
</span><span style="color:#323232;">/dev/sda1       4096   2052095   2048000  1000M EFI System
</span><span style="color:#323232;">/dev/sda2    2052096 481648511 479596416 228.7G Linux filesystem
</span><span style="color:#323232;">/dev/sda3  481648512 500103449  18454938   8.8G Linux filesystem
</span><span style="color:#323232;"> 
</span><span style="color:#323232;"> 
</span><span style="color:#323232;">Disk /dev/sdb: 57.3 GiB, 61524148224 bytes, 120164352 sectors
</span><span style="color:#323232;">Disk model:  SanDisk 3.2Gen1
</span><span style="color:#323232;">Units: sectors of 1 * 512 = 512 bytes
</span><span style="color:#323232;">Sector size (logical/physical): 512 bytes / 512 bytes
</span><span style="color:#323232;">I/O size (minimum/optimal): 512 bytes / 512 bytes
</span><span style="color:#323232;">Disklabel type: dos
</span><span style="color:#323232;">Disk identifier: 0x7498467c
</span><span style="color:#323232;"> 
</span><span style="color:#323232;">Device     Boot   Start     End Sectors  Size Id Type
</span><span style="color:#323232;">/dev/sdb1  *         64 5249887 5249824  2.5G  0 Empty
</span><span style="color:#323232;">/dev/sdb2       5249888 5575519  325632  159M ef EFI (FAT-12/16/32)
</span><span style="color:#323232;"> 
</span><span style="color:#323232;"> 
</span><span style="color:#323232;">Disk /dev/loop0: 2.35 GiB, 2520530944 bytes, 4922912 sectors
</span><span style="color:#323232;">Units: sectors of 1 * 512 = 512 bytes
</span><span style="color:#323232;">Sector size (logical/physical): 512 bytes / 512 bytes
</span><span style="color:#323232;">I/O size (minimum/optimal): 512 bytes / 512 bytes
</span>

Snapper Snapshots:

I recently setup snapshots with Snapper since I’m using BTRFS. From what I understand, I can just roll back my system to before the system update (it takes a snapshot before and after installing anything) but I got confused on how to do that last night - troubleshooting at 2AM with a lack of sleep will do that…

What is the best way forward? I’m happy to provide more information if it helps.

EDIT: Output of lsblk


<span style="color:#323232;">[liveuser@eos-2024.04.20 ~]$ lsblk -f
</span><span style="color:#323232;">NAME   FSTYPE      FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
</span><span style="color:#323232;">loop0  squashfs    4.0                                                                     0   100% /run/archiso/airootfs
</span><span style="color:#323232;">sda                                                                                                 
</span><span style="color:#323232;">├─sda1 vfat        FAT32                        0BC7-CF22                                           
</span><span style="color:#323232;">├─sda2 crypto_LUKS 2                            5c6d5430-3706-48e8-bffb-f680d8c19dda                
</span><span style="color:#323232;">└─sda3 crypto_LUKS 2                            81a912d5-fb81-40ed-a60f-0af27314b661                
</span><span style="color:#323232;">sdb    iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                              
</span><span style="color:#323232;">├─sdb1 iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                     0   100% /run/archiso/bootmnt
</span><span style="color:#323232;">└─sdb2 vfat        FAT16            ARCHISO_EFI 7156-9697  
</span>

EDIT 2:


<span style="color:#323232;">[liveuser@eos-2024.04.20 ~]$ lsblk -a
</span><span style="color:#323232;">NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
</span><span style="color:#323232;">loop0    7:0    0   2.3G  1 loop /run/archiso/airootfs
</span><span style="color:#323232;">sda      8:0    0 238.5G  0 disk 
</span><span style="color:#323232;">├─sda1   8:1    0  1000M  0 part 
</span><span style="color:#323232;">├─sda2   8:2    0 228.7G  0 part 
</span><span style="color:#323232;">└─sda3   8:3    0   8.8G  0 part 
</span><span style="color:#323232;">sdb      8:16   1  57.3G  0 disk 
</span><span style="color:#323232;">├─sdb1   8:17   1   2.5G  0 part /run/archiso/bootmnt
</span><span style="color:#323232;">└─sdb2   8:18   1   159M  0 part 
</span>


<span style="color:#323232;"># /etc/fstab: static file system information.
</span><span style="color:#323232;">#
</span><span style="color:#323232;"># Use 'blkid' to print the universally unique identifier for a device; this may
</span><span style="color:#323232;"># be used with UUID= as a more robust way to name devices that works even if
</span><span style="color:#323232;"># disks are added and removed. See fstab(5).
</span><span style="color:#323232;">#
</span><span style="color:#323232;"># <file system>             <mount point>  <type>  <options>  <dump>  <pass>
</span><span style="color:#323232;">UUID=0BC7-CF22                            /efi           vfat    fmask=0137,dmask=0027 0 2
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /              btrfs   subvol=/@,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /home          btrfs   subvol=/@home,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/cache     btrfs   subvol=/@cache,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/log       btrfs   subvol=/@log,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-81a912d5-fb81-40ed-a60f-0af27314b661 swap           swap    defaults   0 0
</span><span style="color:#323232;">tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
</span>

EDIT 3:

I think I have fixed it. I have chrooted and am busy running sudo pacman -Syu

EDIT 4: /efi still fails to mount.

Wilmo,

Per this article from EndeavourOS discovery I was able to repair my similar issue.

discovery.endeavouros.com/system-rescue/…/12/

However my device wasn’t encrypted. However near the bottom are instructions if you are and they don’t quite match what you said you did. Maybe give it a try?

“Encrypted installs In case /dev/sda2 is the encrypted root partition you need to unlock:

sudo cryptsetup open /dev/sda2 mycryptdevice

It will ask for your LUKS passphrase and unlocks the device into the path /dev/mapper/mycryptdevice

This path can be used to mount the device:

sudo mount /dev/mapper/mycryptdevice /mnt

Followed by mounting the ESP (EFI-System-Partition) into the already mounted system:

sudo mount /dev/sdXn /mnt/efi

where in all cases /dev/sdXn needs to be changed according to what is used on your install as partition/device path and the mount path for the ESP needs to get changed according to your installed system in case. If it is /efi you need to mount on /mnt/efi if it is /boot/efi it would be /mnt/boot/efi …”

Para_lyzed,

Are you able to manually mount the EFI partition while chrooted? Running an update won’t fix the problem if you don’t have the EFI partition mounted properly. To that end, are you able to manually mount the EFI partition at all? That would be a very big problem if not.

While chrooted, try the following before updating:


<span style="color:#323232;">mount /dev/sda1 /efi
</span>

I’m a bit confused by the partitioning scheme, as I don’t see a /boot mount, are the files usually stored in /boot stored in /efi here? Usually the EFI partition only contains EFI binaries. Unless perhaps your /dev/sda3 is a LUKS encrypted boot partition? Sorry, I’m not very familiar with Arch, it’s strange to me to not see a /boot mountpoint in the /etc/fstab

It may be a good idea to just roll back the snapshot if none of this works, though that will only change the btrfs partition, so it won’t fix any issues inside the EFI partition if there are any issues there. Here’s an article about how to do that with btrfs.

governorkeagan,

It was causing me too much of a headache to try troubleshoot and fix that I decided to wipe the drive. I’ve got Fedora Silverblue running on the machine now. Thanks for the help!

Para_lyzed,

Great choice, I’m running Kinoite (Fedora Atomic KDE) myself! The atomic nature of the distros make them less prone to breakage, and much easier to recover from (since you can just roll back to the previous branch instead of restoring a BTRFS snapshot).

bloodfart, (edited )

What does lsblk say?

E: uhh, let me be clear, use lsblk to figure out what the name of your encrypted volume is then append it to the unlock commands. You have to specify both the physical device (/dev/sda2?) and the encrypted volume name.

governorkeagan, (edited ) 

<span style="color:#323232;">[liveuser@eos-2024.04.20 ~]$ lsblk -f
</span><span style="color:#323232;">NAME   FSTYPE      FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
</span><span style="color:#323232;">loop0  squashfs    4.0                                                                     0   100% /run/archiso/airootfs
</span><span style="color:#323232;">sda                                                                                                 
</span><span style="color:#323232;">├─sda1 vfat        FAT32                        0BC7-CF22                                           
</span><span style="color:#323232;">├─sda2 crypto_LUKS 2                            5c6d5430-3706-48e8-bffb-f680d8c19dda                
</span><span style="color:#323232;">└─sda3 crypto_LUKS 2                            81a912d5-fb81-40ed-a60f-0af27314b661                
</span><span style="color:#323232;">sdb    iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                              
</span><span style="color:#323232;">├─sdb1 iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                     0   100% /run/archiso/bootmnt
</span><span style="color:#323232;">└─sdb2 vfat        FAT16            ARCHISO_EFI 7156-9697  
</span>

Would I be able to append the UUID?

bloodfart,

Hmm, I hat about lsblk -a?

governorkeagan, (edited ) 

<span style="color:#323232;">[liveuser@eos-2024.04.20 ~]$ lsblk -a
</span><span style="color:#323232;">NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
</span><span style="color:#323232;">loop0    7:0    0   2.3G  1 loop /run/archiso/airootfs
</span><span style="color:#323232;">sda      8:0    0 238.5G  0 disk 
</span><span style="color:#323232;">├─sda1   8:1    0  1000M  0 part 
</span><span style="color:#323232;">├─sda2   8:2    0 228.7G  0 part 
</span><span style="color:#323232;">└─sda3   8:3    0   8.8G  0 part 
</span><span style="color:#323232;">sdb      8:16   1  57.3G  0 disk 
</span><span style="color:#323232;">├─sdb1   8:17   1   2.5G  0 part /run/archiso/bootmnt
</span><span style="color:#323232;">└─sdb2   8:18   1   159M  0 part 
</span>

EDIT:

I was able to chroot into the drive. The drive was unlocked as /dev/dm-0.

bloodfart,

Wait it was already unlocked and ready to go?

governorkeagan,

Yes and no. Initially it was unlocked because I mounted and unlocked it via Dolphin. The second time round I was able to unlock and mount it with udsiksctl

MsFlammkuchen, (edited )

It looks like /dev/sdb2 is your efi partition. Your disk names probably got swapped. It might be worth to switch to UUIDs. lsblk -f gives you your filesystem types and UUIDs for your partitions.

Edit: This is incorrect.

felsiq, (edited )

sdb looks like the bootable USB to me - /dev/sda1 should be the system’s EFI, no? OP, could you try mounting that one (shouldn’t be encrypted afaik) and/or post the output of cat /etc/fstab? Edit: just realized you were unable to mount the encrypted drive in the first place so /etc is inaccessible, sorry

MsFlammkuchen,

You’re right. /dev/sda1 is the efi partition for the hard drive. I would still be interested in the output of lsblk -f to see what it says about the file system type.

governorkeagan,

I was able to get the output via Emergency Mode as the root user.


<span style="color:#323232;"># /etc/fstab: static file system information.
</span><span style="color:#323232;">#
</span><span style="color:#323232;"># Use 'blkid' to print the universally unique identifier for a device; this may
</span><span style="color:#323232;"># be used with UUID= as a more robust way to name devices that works even if
</span><span style="color:#323232;"># disks are added and removed. See fstab(5).
</span><span style="color:#323232;">#
</span><span style="color:#323232;"># <file system>             <mount point>  <type>  <options>  <dump>  <pass>
</span><span style="color:#323232;">UUID=0BC7-CF22                            /efi           vfat    fmask=0137,dmask=0027 0 2
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /              btrfs   subvol=/@,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /home          btrfs   subvol=/@home,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/cache     btrfs   subvol=/@cache,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/log       btrfs   subvol=/@log,noatime,compress=zstd 0 0
</span><span style="color:#323232;">/dev/mapper/luks-81a912d5-fb81-40ed-a60f-0af27314b661 swap           swap    defaults   0 0
</span><span style="color:#323232;">tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
</span>
felsiq,

Well your /efi entry looks right to me - maybe try mount -a (maybe capital A, going off memory here but whichever option is all) and watch for error messages or check dmesg?

governorkeagan, 

<span style="color:#323232;">NAME   FSTYPE      FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
</span><span style="color:#323232;">loop0  squashfs    4.0                                                                     0   100% /run/archiso/airootfs
</span><span style="color:#323232;">sda                                                                                                 
</span><span style="color:#323232;">├─sda1 vfat        FAT32                        0BC7-CF22                                           
</span><span style="color:#323232;">├─sda2 crypto_LUKS 2                            5c6d5430-3706-48e8-bffb-f680d8c19dda                
</span><span style="color:#323232;">└─sda3 crypto_LUKS 2                            81a912d5-fb81-40ed-a60f-0af27314b661                
</span><span style="color:#323232;">sdb    iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                              
</span><span style="color:#323232;">├─sdb1 iso9660     Joliet Extension EOS_202404  2024-04-20-15-57-10-00                     0   100% /run/archiso/bootmnt
</span><span style="color:#323232;">└─sdb2 vfat        FAT16            ARCHISO_EFI 7156-9697  
</span>

I’ve added it to the original post as well.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • GTA5RPClips
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • tacticalgear
  • cubers
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • osvaldo12
  • ngwrru68w68
  • kavyap
  • InstantRegret
  • JUstTest
  • everett
  • Durango
  • cisconetworking
  • khanakhh
  • ethstaker
  • tester
  • anitta
  • Leos
  • normalnudes
  • modclub
  • megavids
  • provamag3
  • lostlight
  • All magazines
    •