Emergency mode: Failed to mount /boot/efi ('vfat' error) - Tried base reinstall, issue persists

[gr4mm]

Hello everyone,

I’m seeking help with a boot issue that began immediately after a routine system update (yay -Syu). I’ve tried all the common solutions, including those from a similar solved topic, but the problem persists.

The Problem:
My system drops into an emergency shell on boot with the error: [FAILED] Failed to mount /boot/efi. The underlying cause is unknown filesystem type 'vfat'.

The Core Puzzle:
The key issue is that the vfat.ko kernel module is present in my initramfs images (verified with lsinitrd). The system has the driver but fails to load or use it.

What I Have Already Done (all steps performed from arch-chroot):

1. Checked EFI Partition: The partition is healthy. fsck.vfat reports no errors.
2. Checked /etc/fstab: The UUID is correct and configuration is valid.
3. Reinstalled GRUB: I have tried fully reinstalling the bootloader (grub-install) and regenerating the config (grub-mkconfig). This did not help.
4. Attempted “Missing Packages” Fix: I ran pacman -Syu base --needed to restore any potentially missing core packages. The command completed, but the issue was not resolved.
5. Rebuilt Initramfs: A full dracut-rebuild was performed after every attempted fix.

Despite all this, the system still fails with the exact same error.

System Information & Logs:

Here is the diagnostic data from my system:

• lsblk -f:

  NAME        FSTYPE   FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
  loop0       squashfs 4.0                                                         0   100% /run/archiso/airootfs
  sda                                                                                       
  └─sda1      vfat     FAT32 EOS_202503 1412-4040                              54.8G     5% /run/archiso/bootmnt
  nvme0n1                                                                                   
  ├─nvme0n1p1 vfat     FAT32            D814-067F                                           
  └─nvme0n1p6 ext4     1.0              b4ca3a6e-f5ec-4093-9642-92096be5c972   
  

• cat /etc/fstab:

  # /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=D814-067F                            /boot/efi      vfat    fmask=0022,dmask=0022 0 2
  UUID=b4ca3a6e-f5ec-4093-9642-92096be5c972 /              ext4    noatime    0 1
  tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
  /swapfile none swap defaults 0 0
  
  

• Boot Log (journalctl):
  I have uploaded the full boot log using eos-sendlog. Please find it at the URL below:

  https://0x0.st/KS9q.txt
  

Given that the error started after an update and that standard recovery methods have failed, I suspect a more complex issue. I would be very grateful for any ideas on what to check next.

Thank you.

[keescase]

That looks really weird because this is how my seup looks

─nvme1n1p1 vfat   FAT32             6167-0194                                 2G     2% /boot/efi
└─nvme1n1p2 ext4   1.0   EosPlasma   0fb20ddc-c04b-4ed8-a2a1-7014703d5616  408,2G     5% /

So it looks like you are missing a /boot/efi on your fat32 partition.

[cactux]

From chroot, please post:

pacman -Q | grep -E "dracut|grub|mkinitcpio”

ls /boot

[cactux]

They are posting lsblk -f from the live iso, that is why the mountpoints don’t show.

[gr4mm]

Here is the output you requested from the chroot environment.

• pacman -Q | grep -E "dracut|grub|mkinitcpio":

  [root@EndeavourOS /]# pacman -Q | grep -E "dracut|grub|mkinitcpio"
  dracut 108_eos-1
  eos-dracut 1.7-1
  grub 2:2.12.r418.g6b5c671d-1
  

• ls /boot:

  [root@EndeavourOS /]# ls /boot
  amd-ucode.img  initramfs-linux-lts-fallback.img  initramfs-linux-zen.img
  efi            initramfs-linux-lts.img           vmlinuz-linux-lts
  grub           initramfs-linux-zen-fallback.img  vmlinuz-linux-zen
  

[cactux]

Everything you have posted seems correct to me. Wonder what is causing the issue

Two things I would try personally:

1. booting off of the fallback images

2. trying early kernel module loading:
   https://wiki.archlinux.org/title/Dracut#Early_kernel_module_loading

I think you should put in vfat for the module. Do some research.
You need to rebuild your initrds after adding the file.

As a last try, I would reinstall all the kernels.

Hopefully one of these steps will work. If not, I have no more ideas.

[gr4mm]

DUDE THIS IS INCREDIBLE! ADDING VFAT IS WORKING! I’ve been trying this for days and for some reason, this time it worked!

The last thing I did was create the /etc/dracot.conf.d/force-vfat.conf file and run dracut-rebuild. The system now successfully mounts /boot/efi and gets to the login screen.

Here is the proof:

But now I have a new problem. After I enter my password at the login screen, the screen just goes black and my desktop never loads.

Before the Login Manager loads, I can see some errors flash on the screen, but they disappear too quickly for me to read. I’m guessing it’s an NVIDIA driver problem now. What’s the next step to fix that?

[cactux]

@gr4mm

The last thing I did was create the /etc/dracot.conf.d/force-vfat.conf file and run dracut-rebuild. The system now successfully mounts /boot/efi and gets to the login screen.

Glad to hear that you got it working!

@gr4mm

But now I have a new problem. After I enter my password at the login screen, the screen just goes black and my desktop never loads.

Before the Login Manager loads, I can see some errors flash on the screen, but they disappear too quickly for me to read. I’m guessing it’s an NVIDIA driver problem now. What’s the next step to fix that?

I’m afraid I cannot be of help regarding the issues with NVIDIA. I don’t use it so my knowledge about troubleshooting and fixing is “theoretical”, at best. There are highly more capable forum members in this field who may be able to help you.

I suggest to open a new thread for this new issue.

One thing you could do is to boot past your graphical environment following this guide.

https://discovery.endeavouros.com/system-rescue/how-to-boot-without-a-graphical-environment/2021/03/

Once you log in from TTY, you can get some logs:

https://discovery.endeavouros.com/forum-log-tool-options/how-to-include-systemlogs-in-your-post/2021/03/