[UEFI][GRUB] Boot repair keeps adding MokManager.efi to boot menu

Question

I had trouble installing Arch along with Ubuntu (it didn't load the FAT32 esp). I ran boot-repair thinking that it could solve the problem. But it added MokManager.efi to the list of grub boot menu.

Here's what I did -

1. Formatted the Arch partition.
2. Created a backup of my /boot partition.
3. Deleted all stuff from /boot/efi.
4. Placed the memtest86+, config, System.map, initrd and vmlinuz files in both, /boot and /boot/efi of the FAT32 boot partition.
5. checked the updated the /etc/grub.d/25_custom file by removing the MokManager entries.
6. Ran update-grub
7. Ran boot-repair again

But for some reason boot-repair again added MokManager.efi files to the /boot/efi/ubuntu and /boot/efi/efi/ubuntu folders. I am also not sure why it keeps making an efi folder in /boot/efi. But it comes up again on the next boot-repair.

I could just backup my home folder and reinstall the whole thing, but I don't understand where the MokManager files keep propping up from. Any idea about this?

Solution

First, know that MokManager.efi is a tool for managing Machine Owner Keys (MOKs), which are Secure Boot keys used by Shim to enable you to boot OSes of your choice when Secure Boot is active. If Secure Boot is active on your computer, you probably should have MokManager installed and accessible from GRUB, so that you can boot emergency tools of your choice should the need arise. If Secure Boot is inactive or unsupported on your computer, MokManager is dead weight -- but it's not a lot of dead weight, so I wouldn't worry too much about it. (You'll find far more useless cruft in any out-of-the-box Linux distribution, and few people go digging through all those files to clean it out.)

That said, my guess is that Boot Repair is finding the MokManager.efi binary in files installed from the shim package. Specifically, the file is /usr/lib/shim/MokManager.efi.signed (it's renamed to omit the .signed extension when it's copied to the ESP). If you really don't need Secure Boot, you could try removing that package -- but other packages may depend on it, so you may need to remove more than just that one. OTOH, if you're running Boot Repair from a live CD, it's conceivable that it's pulling MokManager from there rather than from your regular installation, so removing the files from your regular installation may be ineffective. For similar reasons, editing your local GRUB configuration files might not do much good.

Placed the memtest86+, config, System.map, initrd and vmlinuz files in both, /boot and /boot/efi of the FAT32 boot partition.

The "FAT32 boot partition" is known as the EFI System Partition (ESP). If you're using GRUB, there's no need to copy most of those files to the ESP, and certainly not to the boot or boot/efi directory on that partition. Neither of those directories exists by default on the ESP. Note, though, that the ESP is normally mounted at /boot/efi, so from your description, you may have copied those files to /boot in your normal Ubuntu distribution and/or to the root of the ESP. (It's critical to understand mount points when dealing with the ESP. The EFI may see a file as fs0:\EFI\ubuntu\grubx64.efi, but that file would likely be /boot/efi/EFI/ubuntu/grubx64.efi in Ubuntu. You "erase" the mount point from the complete Ubuntu file path to determine where the file is on the partition itself. The EFI has no idea of what the Ubuntu mount point is, and so accesses the file without using the Ubuntu mount point.)

Of those files, most of them belong in the Ubuntu /boot directory, which is not on the ESP. (In some cases, /boot is a separate partition itself.) Various memtest86+* files should go in /boot, too, placed there automatically by the memtest86+ package. There should be no need to adjust any of these. If you've been copying those files to achieve some specific goal, perhaps you should share that goal, since it's unlikely that you're doing the right thing unless you've omitted some critical details (such as if you're planning to use gummiboot/systemd-boot on your computer).

Generally speaking, all of this stuff should Just Work. If it's not working, then something is wrong, and the actions you've described are unlikely to help, so knowing what's wrong is critical for helping you. If you simply want to remove MokManager from your GRUB menu, I recommend you not bother -- and if you insist on trying, copying your kernel and other files will not help; you need to adjust the GRUB configuration files and run update-grub. (I'm afraid I don't know precisely what you'd do to remove MokManager.) Alternatively, you could switch from GRUB to any of the several other EFI boot loaders for Linux.

Comments

[goelakash]

Thanks for the explanation Rod. I copied those files in the /boot and /boot/efi folders because apparently boot-repair was not recognizing GPT partition without them (I tried with an empty boot folder with an empty efi folder inside it).

[goelakash]

I figured how to remove MokManager though - by editing the 25_custom file and updating grub afterwards. I am guessing that boot-repair will generate them the next time though. (Even when I uncheck secure-boot in Advanced options)

[Rod Smith]

I've never heard of Boot Repair requiring anything anywhere in the boot directory tree on the ESP. I therefore suspect that something else was happening and you've misidentified the causal relationship.