Ask Your Question

Grub2 w/ UEFI does not pick up new kernels even after upgrade to Fedora 27

asked 2017-11-29 11:10:54 -0500

robbiethek gravatar image

updated 2017-12-01 14:05:38 -0500

I'm having the exact problem as noted in F20/64bit/UEFI - latest kernel update breaks boot - any clue? as well as Kernel update 3.12.10 breaks boot: unable to mount /boot/efi - vfat not recognised and Grub does not pick up new kernels and SELinux is disabled, UEFI is enabled.

When I try this:

mount /dev/disk/by-uuid/271C-95B0
/boot/efi mount: /boot/efi: unknown
filesystem type 'vfat'.

In order to boot normally I had to comment out in

#UUID=271C-95B0          /boot/efi               vfat    umask=0077,shortname=winnt 0 2

In journalctl -xb I see these errors:

Nov 29 11:40:23 systemd[1]: proc-fs-nfsd.mount: Mount process exited, code=exited status=32
Nov 29 11:40:23 systemd[1]: Failed to mount NFSD configuration filesystem.
-- Subject: Unit proc-fs-nfsd.mount has failed
-- Unit proc-fs-nfsd.mount has failed.
-- The result is failed.
Nov 29 11:40:23 systemd[1]: Dependency failed for NFS Mount Daemon.
-- Subject: Unit nfs-mountd.service has failed
-- Unit nfs-mountd.service has failed.
-- The result is dependency.
Nov 29 11:40:23 systemd[1]: Dependency failed for NFS server and services.
-- Subject: Unit nfs-server.service has failed
Nov 29 11:40:23 systemd[1]: nfs-idmapd.service: Job nfs-idmapd.service/start failed with result 'dependency'.
Nov 29 11:40:23 systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Nov 29 11:40:23 systemd[1]: nfs-mountd.service: Job nfs-mountd.service/start failed with result 'dependency'.
-- Unit nfs-server.service has failed.
-- Unit var-lib-nfs-rpc_pipefs.mount has failed.
-- The result is failed.
Nov 29 11:40:29 systemd[1]: Dependency failed for
-- Subject: Unit has failed
-- Unit has failed.
-- The result is dependency.
Nov 29 11:40:29 systemd[1]: Dependency failed for RPC security service for NFS client and server.
-- Subject: Unit rpc-gssd.service has failed
-- Unit rpc-gssd.service has failed.
-- The result is dependency.
Nov 29 11:40:29 systemd[1]: rpc-gssd.service: Job rpc-gssd.service/start failed with result 'dependency'.
Nov 29 11:40:29 systemd[1]: Job failed with result 'dependency'.
Nov 29 11:40:29 systemd[1]: var-lib-nfs-rpc_pipefs.mount: Unit entered failed state.

And the contents of

ls -l /boot
total 374419
-rw-r--r--. 1 root root   185327 Jul 17 12:45 config-4.11.11-300.fc26.x86_64
-rw-r--r--  1 root root   185791 Jul 17 12:29 config-4.11.11-300.fc26.x86_64+debug
-rw-r--r--  1 root root   185282 Jul 21 12:56 config-4.11.12-200.fc25.x86_64
-rw-r--r--  1 root root   185757 Jul 21 12:38 config-4.11.12-200.fc25.x86_64+debug
-rw-r--r--  1 root root   188407 Aug  7 11:40 config-4.12.5-300.fc26.x86_64
-rw-r--r--  1 root root   188871 Aug  7 11:25 config-4.12.5-300.fc26.x86_64+debug
drwxr-xr-x. 2 root ...
edit retag flag offensive close merge delete


Please post boot command line: dmesg | grep "Command line" and complete fstab.

fcomida gravatar imagefcomida ( 2017-11-29 16:52:49 -0500 )edit

added in original post

robbiethek gravatar imagerobbiethek ( 2017-11-30 13:15:15 -0500 )edit

The error output in journalctl has to do with NFS, not UEFI. I may not provide much help, but you might want to provide the output of the "blkid" command. My install uses UEFI (but not using secure boot). Additionally, what happens when you try to mount the partition without using UUIDs? The BLKID command should give you a device name (non-UUID) in leftmost column, for example, my EFI partition is /dev/sda1. What happens when you try sudo mount /your/efi /some_empty_directory

lovepump gravatar imagelovepump ( 2017-11-30 13:54:43 -0500 )edit

Thanks @lovepump I edited the original post. How can you enabled UEFI and not secure boot aren't they the same thing? I realize the NFS errors might not be related to the Grub issue but may be a symptom of it or a clue.

robbiethek gravatar imagerobbiethek ( 2017-11-30 14:11:25 -0500 )edit

@robbiethek. Think of UEFI as a sophisticated replacement for what used to be called the BIOS. Secure boot is a feature of UEFI that allows you to ensure that what you boot is actually signed by the manufacturer or it will prevent loading. This makes it harder for something malicious to change your kernel, like a root kit might do. Fedora provides "shim" which (as far as I know) is a signed variant of grub2. This variant of grub has to be located somewhere on your EFI partition, mine resides in /boot/efi/EFI/fedora, where /boot/efi is the mountpoint on my system for my EFI partition.

lovepump gravatar imagelovepump ( 2017-11-30 15:09:14 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2017-12-03 23:56:40 -0500

cmurf gravatar image

updated 2017-12-03 23:57:53 -0500

I have another idea. Download a netinstall image, and make bootable media, and boot it. In the boot menu there's a troubleshooting option, pick that, then choose the rescue a Fedora system option, pick that. Eventually you'll get a text menu, pick the first option to continue. If your fstab is correct, it will assemble things for you, and you can

chroot /mnt/sysimage
sudo dnf reinstall shim grub2-efi kernel kernel-*
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

This sequence will not work if your fstab is still malformed, good chance the installer's rescue will fail to assemble the Fedora system. So you'll have to go about finding and fixing the fstab, and then either manually assemble the system, and then chroot; or just reboot the netinstall media, repick Troubleshooting > Rescue > Continue and proceed with chroot et al per above. And while you're at it, good idea to capture efi boor vars with

efibootmgr -v | fpaste
edit flag offensive delete link more


Ah @cmurf thank you thank you thank you! That did it! I probably should've started this thread also mentioning that this machine did have an rsync done to it from another similar system. I was under the impression that /etc/fstab was not as important as it used to be and simply commented out the UUIDs of /boot and /boot/efi and apparently this didn't become a problem until the oldest kernel in /boot was removed. Thanks for your patience and helping me. Quite the learning experience.

robbiethek gravatar imagerobbiethek ( 2017-12-05 13:23:36 -0500 )edit

Yeah so upvote my answer and tick the checkbox for correct answer, since I'm hoarding Ask Fedora points (I'm just being silly). Yes /etc/fstab is still used to fully assemble Fedora systems, and they need to be assembled for updates to apply correctly. It's possible to obsolete fstab using special systemd specific GPT partition type GUIDs so it knows what to mount, but this is not a default configuration yet on Fedora.

cmurf gravatar imagecmurf ( 2017-12-05 16:56:38 -0500 )edit

answered 2017-11-30 17:14:52 -0500

cmurf gravatar image

/boot/efi is vfat, vfat is a module, and modules are kernel version specific. You're booting 4.12.5 kernel and initramfs, but that package is deleted, which means the modules are gone, which means vfat can't be found. DNF only keeps three kernel versions around at one time, and then starts deleting them so they don't accumulate. But because /boot/efi is commented out in fstab and not mounting, /boot/efi/EFI/fedora/grub.cfg can't be updated when new kernels are installed, and that's why grub doesn't contain any reference of your new kernels. Also, because /boot/efi is commented out, the hostonly initramfs for all your installed kernels won't have vfat embedded in them. And this has been going on for a long time because you've got a bunch of kernels on /boot whose packages were removed by dnf long ago, suggesting /boot also hasn't been mounted some of the time.

First you need to fix your fstab so that it contains the proper UUID for your efi system partition, so that /boot/efi can mount. You can add the mount option in fstab 'nofail' so that problems with /boot/efi don't cause boot hangs. Next, download new kernel packages:

$ sudo dnf reinstall --downloadonly kernel*

That will download the 4.13.15 kernel packages, it will not install them. Reboot, and in grub, pick the rescue boot entry, and edit it. Add a 1 to the kernel command line so you boot single user mode. This nohostonly initramfs will have vfat embedded and when you get to a prompt and login, you should use df to confirm that /boot and /boot/efi are both mounted. And if they are you can do:

$ sudo dnf reinstall kernel*

If that's fussy, you might need to add -C after dnf so it uses the cache instead of trying to download, which it can't in single user.

Now you should get a boot entry 4.13.15 that works normally, and now you can start cleaning up /boot from these old kernels and initramfs that do not have packages installed on your system; and when you're done making sure you only have matching kernels and initramfs with installed packages, you can blow away the stale grub.cfg with

$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
edit flag offensive delete link more


Before you do anything else, including what is suggested below by cmurt, you NEED to figure out if you are booting your machine in legacy BIOS mode or in UEFI mode. Everyone who has answered here is assuming you are booting into UEFI mode. Whether or not you have files sitting in your UEFI partition is MEANINGLESS unless those are the files your machine (grub2) has been told to use while booting. Additionally, I can see now from your fstab file, that it is PROBABLE that the UEFI partition on this system was created by a windows installation, given the "shortname=winnt". Are you dual-booting?

lovepump gravatar imagelovepump ( 2017-11-30 22:00:24 -0500 )edit

The reason I am emphasizing this, is that your kernel/initrd/initramfs does not "know" what the vfat filesystem is. This is why you are getting the error mounting it. It indicates to me it is NOT a kernel/initrd/initramfs that was made to boot using UEFI. You MAY have managed to place a non-vfat capable kernel/initramfs on your UEFI partition and told a non-UEFI grub2 (that still can use vfat filesystems) to boot to it. More importantly, if you use the grub2-mkconfig command with the grub.cfg path cmurt has suggested, it will modify the grub.cfg file that is used when booting using UEFI mode.

lovepump gravatar imagelovepump ( 2017-11-30 22:11:00 -0500 )edit

If you aren't booting in UEFI mode, it is LIKELY changing the grub.cfg file with grub2-mkconfig command isn't going to do jack-shit for you, because legacy grub2 isn't going to by default want to "work" with a vfat filesystem, nor is it going to want to look for its configuration files on your UEFI partition by default. Find out whether your machine is set to boot using UEFI mode or legacy BIOS mode. Then and ONLY then will you know HOW and WHERE to start making fixes.

lovepump gravatar imagelovepump ( 2017-11-30 22:18:41 -0500 )edit

@lovepump I tried changing to Legacy mode and got the Attempting to boot from hard drive message. Then switched to UEFI and now I'm getting "no option to boot to". I can get to rescue mode at least. Not sure where to go from here. When I run:


[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

And these files are present : -r--r--r--. 1 root root 4096 Dec 1 15:00 configtable drwxr-xr-x. 2 root root 0 Dec 1 14:41 efivars -r--r--r--. 1 root root 4096 Dec 1 15:00 fwplatformsize -r--r--r--. 1 root root 4096 Dec 1 15:00 fwvendor

robbiethek gravatar imagerobbiethek ( 2017-12-01 14:02:42 -0500 )edit

OK so you know you're booting into UEFI mode rather than legacy mode. You can go ahead and try what cmurt has suggested when in rescue mode, because you know the path he has given to grub.cfg in his answer is the default path that fedora places the grub.cfg file (given that /boot/efi/ is the mountpoint of your EFI partition). However first, make sure to fix the UUID in /etc/fstab as cmurt also suggested, the blkid command lists the UUID for your EFI partition and rather than commenting it out in fstab, make it match what blkid says it is and see if you're good.

lovepump gravatar imagelovepump ( 2017-12-01 23:43:54 -0500 )edit

Question Tools



Asked: 2017-11-29 11:10:54 -0500

Seen: 1,388 times

Last updated: Dec 03 '17