Ask Your Question

Kernel update 3.12.10 breaks boot: unable to mount /boot/efi - vfat not recognised

asked 2014-02-12 22:51:59 -0600

dm3k gravatar image

updated 2014-02-13 13:30:46 -0600

mether gravatar image

Initially asked in Fedoraforums, but problem persists.

System description EFI-enabled desktop computer AMD CPU, AMD GPU MSI FM2-A55M-P33 Fedora 20 x86-64 XFCE spin is the sole installed OS

2 SATA disk - partition scheme sda /boot/efi vfat LVM --- / ext4 --- /boot ext4 --- /home ext4 --- /swap

sdb Empty. No partitions, no files. Connected just for future use.

gdisk -l /dev/sda

1  200MiB EF00 EFI System Partition
2  500MiB 0700
3  595.5GiB 8E00


Yum-update completed ~30 hours ago. That install kernel 3.12.10. Updated, then set selinux to relabel filesystem (I had temporarely disabled selinux after some issues, and I was enabling it again). Rebooted a few hours after updating.

I was expecting to have to install AMD drivers, like it's needed after every kernel update, but in the past, I could boot in XFCE just fine. This time, the boot process stalled before that. I initially thought it was a graphics problem, but it seems it's a problem with the /boot/efi partition.

No installed kernel will boot. Only the rescue mode entry can boot.

This is where boot stalls with quiet on

   Stating Wait for Plymouth Boot Screen to Quit...
   Mounting Arbitrary Executable File Formats File System

This is where it stalls with quiet off

image description

Rescue mode gave some insight to the issue: /boot/efi cannot be mounted, vfat is not a recognised filesystem type image description

I checked /var/log/messages from rescue mode

I can see

systemd: Failed to add job sys-kernel-config.mount/start, ignoring: Invalid argument

ls /boot/efi returns no contents at all, so I assume /boot/efi is not mounted. Yet, I can see GRUB, three kernels (that won't boot) and the rescue mode. There is no other grub.cfg file in the system.

Manual mount ends in error:

mount: unknown filesystem type 'vfat'

I tried using fsck.vfat -r on the EFI partition, changed nothing, thought it says it fixed the 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

I tried reinstalling the kernel, kernel-headers, kernel-modules-extra, kernel-devel to the most recent version, 3.12.10. I checked and msdosfstools is indeed installed. Did all that from rescue mode.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-04-29 00:56:24 -0600

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

Hi there. I'm answering this for posterity because I recently came across this question when I was searching for the very same problem.

So here's what's going on... For whatever reason modules aren't being loaded properly for your rescue kernel, and, while you may be able to boot no problem, and network ( dhclient <dev> ) - what you will most likely not be able to do is use DNF to install the kernel modules you need (my rescue kernel was 4.4.6 for example, and all that was left in the repository was 4.4.8)

The main problem is that Fedora isn't building with vfat inside the kernel - so what happens is even when you go to update your grub.cfg while the rescue kernel is booted. /boot/efi/ is nothing more than a folder on /boot at that point. Recall that on a UEFI system there is; /boot/ and /boot/efi mountpoints. By default /dev/sda1 -> /boot/efi and /dev/sda2 -> /boot So we can regenerate initramfs/grub.cfg and this isn't going to do anything since the partition is unmounted, yet we can not mount the partition.

Bit of conundrum, eh? Well what we do have is 1. A running kernel 2. Presumably network ability 3. Possibly kernel modules for a newer kernel. So let's make sure we have the latest kernel with dnf install --best kernel

Observe now that there should be a /lib/modules/<kernel_ver> corresponding to the version you just installed (or already had installed) after installing the kernel-modules package, which kernel should have pulled in.

So next we have to think.... What do we have at our disposal? Initramfs isn't going to help, that resides on /boot/, adding rd.break isn't going to help, because that stops the initramfs from switching roots - but the only kernel we can boot is the rescue kernel and it still doesn't have the right vfat modules!

Ah! What we do have is our disposal is a working entry in the grub.cfg that we can not reach, and this points to a certain kernel, the rescue kernel itself.

All you have to do at this point is cd /boot and copy the rescue kernel somewhere (preferably by adding a .old to the end or something) and then copy the current kernel that you CAN download stuff for, as the exact name of the rescue kernel.

Then when you reboot and select the rescue kernel again, it will boot the current kernel, equipped with all the necessary trimmings and modules. From here you can get into /boot and /boot/efi and fix things up to your liking, generate initramfs with dracut, etc.


edit flag offensive delete link more


I'm having the problem and it actually started before upgrading to Fed27, which I thought would fix it. I'm trying to understand your next to last paragraph. How do I find the exact name of the rescue kernel? In /lib/modules/ I have: 4.12.9-300.fc26.x8664

Can you clarify for me?

robbiethek gravatar imagerobbiethek ( 2017-11-29 10:18:14 -0600 )edit

answered 2014-02-13 02:18:56 -0600

updated 2014-02-13 02:19:47 -0600

Boot the rescue entry, and try regenerating your initramfs, as in

edit flag offensive delete link more


Thanks. That sadly didn't work. dracut was successful, but it didn't fix the boot issues.

I'm afraid I will have to reinstall, and won't be able to test further proposed solutions. The machine has been out of operation for three days, I can afford to have it like that longer.

dm3k gravatar imagedm3k ( 2014-02-13 17:01:01 -0600 )edit

Question Tools



Asked: 2014-02-12 22:51:59 -0600

Seen: 6,458 times

Last updated: Apr 29 '16