Linux @lemmy.ml governorkeagan @lemdro.id 6 mo. ago

[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:

[FAILED] Failed to mount /efi
See 'systemctl status efi.mount` for details.

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:

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

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

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

EDIT 2:

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

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

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.

You're viewing a single thread.

16 comments

~~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.
- 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
  
  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.
  
  I was able to get the output via Emergency Mode as the root user.
  
  # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a device; this may # be used with UUID= as a more robust way to name devices that works even if # disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> UUID=0BC7-CF22 /efi vfat fmask=0137,dmask=0027 0 2 /dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda / btrfs subvol=/@,noatime,compress=zstd 0 0 /dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /home btrfs subvol=/@home,noatime,compress=zstd 0 0 /dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/cache btrfs subvol=/@cache,noatime,compress=zstd 0 0 /dev/mapper/luks-5c6d5430-3706-48e8-bffb-f680d8c19dda /var/log btrfs subvol=/@log,noatime,compress=zstd 0 0 /dev/mapper/luks-81a912d5-fb81-40ed-a60f-0af27314b661 swap swap defaults 0 0 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
  
  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?
- NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS loop0 squashfs 4.0 0 100% /run/archiso/airootfs sda ├─sda1 vfat FAT32 0BC7-CF22 ├─sda2 crypto_LUKS 2 5c6d5430-3706-48e8-bffb-f680d8c19dda └─sda3 crypto_LUKS 2 81a912d5-fb81-40ed-a60f-0af27314b661 sdb iso9660 Joliet Extension EOS_202404 2024-04-20-15-57-10-00 ├─sdb1 iso9660 Joliet Extension EOS_202404 2024-04-20-15-57-10-00 0 100% /run/archiso/bootmnt └─sdb2 vfat FAT16 ARCHISO_EFI 7156-9697
  
  I've added it to the original post as well.

You've viewed 16 comments.