/boot/efi can't be mounted after kernel update Ubuntu 13.04

Question

After installing the latest updates it appears that the new version of the kernel which was installed (3.8.0-29) will not boot properly.

Whenever I try to boot using this new kernel, I get an error message indicating that there was an error mounting /boot/efi.

This only happens with this new kernel, as starting up with the older kernel versions works fine.

In case this helps, I have a laptop with UEFI, and I dual boot Ubuntu 13.04 and Windows 8.

Edit: I tried everything in Rod Smith's answer but I am still having the issue

The exact error message is:

An error occurred while mounting /boot/efi.

Press S to skip mounting or M for manual recovery

Pressing S just brings me to a terminal login screen, while pressing M brings me to a recovery terminal.

Here are the the results of the commands you asked me to run:

$ grep efi /etc/fstab
# /boot/efi was on /dev/sda2 during installation
UUID=F433-DF4C  /boot/efi       vfat    defaults        0       1

$ sudo blkid
/dev/sda1: LABEL="WINRE_DRV" UUID="4A46311E46310C67" TYPE="ntfs" 
/dev/sda2: LABEL="SYSTEM_DRV" UUID="F433-DF4C" TYPE="vfat" 
/dev/sda3: LABEL="LRS_ESP" UUID="5034-7FB2" TYPE="vfat" 
/dev/sda5: LABEL="Windows8_OS" UUID="989E38469E381F66" TYPE="ntfs" 
/dev/sda6: LABEL="LENOVO" UUID="32EE3B04EE3AC041" TYPE="ntfs" 
/dev/sda7: LABEL="PBR_DRV" UUID="14243C89243C703A" TYPE="ntfs" 
/dev/sda8: UUID="b5377bd7-1953-4cb0-b30d-9ee5a466760c" TYPE="ext4" 
/dev/sda9: UUID="be7e2af0-3cc7-4e3c-82a1-e28e3d4b4ba6" TYPE="swap" 
/dev/sdb1: LABEL="CRUZER" UUID="28A2-35DE" TYPE="vfat" 

While /dev/sda2 and /dev/sda3 both look similar on my system /dev/sda2 is the one with the "boot" flag, and changing the entry in fstab to the UUID for /dev/sda3 made no difference.

Solution

I just updated my Ubuntu 13.04 system to kernel 3.8.0-29 and I had no problem with this. My suspicion is that you're experiencing filesystem damage. This is common on systems that dual-boot with Windows 8 because of a Windows 8 feature called "fast startup." This feature essentially turns the shutdown operation into a suspend-to-disk operation. This works fine on a single-boot computer, but when the computer dual-boots with another OS, the result is dangerous filesystem problems, at least on any filesystem that's shared between OSes (including the EFI System Partition [ESP]). To fix this, boot to Windows and disable fast startup. Note that this feature is not the same as the fast boot option in your firmware; disabling this feature in the firmware does not disable it in Windows 8.

If you disable fast startup and the problem persists, then you could try doing a filesystem check on your ESP, as in dosfsck /dev/sda1. (The device file in Linux might be different, though. Use parted or GParted to find the FAT partition with a "boot flag" set, or use gdisk to find the partition with a type code of EF00.)

If the problem persists even after you disable fast boot and fix the filesystem, please try the following diagnostics:

grep efi /etc/fstab
sudo blkid

Compare the results -- the /etc/fstab file defines where partitions are mounted, and so searching it for efi should produce details on how your system is mounting the ESP. For instance, on my system, it shows the following:

$ grep efi /etc/fstab
# /boot/efi was on /dev/sda1 during installation
UUID=FFB3-46B6  /boot/efi   vfat    defaults    0   1

The blkid command produces information on all your computer's filesystems. You want to compare what it shows for your ESP (usually /dev/sda1, /dev/sda2, or /dev/sda3) to what's in /etc/fstab. For instance:

$ sudo blkid
/dev/sda1: SEC_TYPE="msdos" LABEL="ESP" UUID="FFB3-46B6" TYPE="vfat" 
/dev/sda2: LABEL="Fred" UUID="421258c1-e9b1-4b1b-9dd7-60b82e75f8c3" TYPE="ext4" 
/dev/sda3: UUID="9108d33b-855d-49ba-8b9e-90f981a597ea" TYPE="swap"

In this case, /dev/sda1 is the ESP -- it's a FAT (TYPE="vfat") filesystem, and its serial number matches what's in /etc/fstab (UUID="FFB3-46B6"), so all is in order. A mismatch of the serial numbers or some other detail might cause the problem you're encountering. If you need more help, please edit your post with this information and the exact error message you're seeing.

Comments

[Rod Smith]

Try sudo dosfsck -a /dev/sda2 to automatically repair the ESP. If that doesn't help, post the output of the command.

[Andrew Roskuski]

@RodSmith It seems to be working now, but, due to some carelessness on my part, I'm not entirely sure what fixed it. I ran sudo dosfsck -a /dev/sda2, but I forgot to reboot afterwards, and I also decided to try reinstalling the kernel. One or both of those things worked, but I'm not sure which.

[Andrew Roskuski]

I tried your suggestions but I'm still having the problem. See the updated info in my question.