For anyone doing some regular #linux system updates (especially since 2.12 got flagged "stable" on #gentoo), grub 2.12 changes the EFI install directories and enables shim lock by default, in the news update it tells you about the install directories (simply blow away your /boot/EFI and let grub rebuild it, way better than their instructions), the shim lock is a bit more tricky, it seems to not be working correctly in 2.12 and even with SB disabled trips up.
2/2
tested on my two machines the --disable-shim-lock on install DOES work (you also HAVE to delete the EFI files) but I'm still unsure why secure boot is trying to be used, for the sake of my sanity and systems I rolled back to grub 2.06 and masked 2.12 for now.
@raptor85 the shim lock shouldn't do anything unless you're booting from the shim bootloader. That is if you have shim installed as BOOTX64.EFI and then grub installed separately. If you're booting from GRUB directly it shouldn't matter.
@gabrielesvelto shouldn't, but is, I don't mess with that other stuff at all, I had a pretty simple grub config. Not sure why but I tried it on two of my machines during my upgrade last night and was unable to boot until both the files in the EFI directory were blown away (it duplicated the file on a new path so i had 2.06 and 2.12 files, this is documented in the news post though) AND the shim lock disable set.
@gabrielesvelto that was my thought as well, that if grub-install is run without the feature being disabled it defaults to looking for that always (which is what others ran into in the bug report I posted). The ebuild on gentoo did have a note on the duplicate files issue but comment 2 in the bug report is what I needed to do to get booting again. I don't use secure boot either.
Either way, kinda nasty that a straight upgrade leaves the system unbootable imho it should default to 2.06 behavior
Add comment