Mint fails to boot with a kernel panic when using LVM on EFI systems

[david wood]

On Mint 17, install the system in UEFI mode, with a single root volume in LVM.

I believe you'll find that boot always fails with a kernel panic. At least, it did for me.

After experimentation I discovered that boot-repair could fix the problem, but any run of update-grub afterwards would break booting and restore the same kernel panic.

Comparison of the working and broken states led to the discovery that update-grub was omitting the initrd line in grub.cfg for the current preferred boot option. It was still present within "Previous versions" of linux. Restoring it fixes the problem.

Further investigation led me to /etc/grub.d/10_linux, where the configuration is constructed. It appears that the presence of ".efi.signed" on the end of the live kernel name causes the code within that grub configuration builder to fail to recognize the presence of the initrd. The kernel may boot without the initrd under some circumstances, concealing the problem, however if your root volume is on LVM (or any other circumstance requires the initrd to boot), you will have boot failure.

Upstream Ubuntu does not appear to have this problem as of 14.04.

Fixes could include creation of a symlink or copy of the initrd to match the "*.efi.signed" naming of the "vmlinuz*.efi.signed" kernel file, or changes to the grub config building logic to recognize initial ramdisks in the EFI booting scenario.

I fixed this problem the latter way, temporarily, by patching 10_linux to specifically recognize the initrd for the current kernel version despite the presence of "*.efi.signed" naming in the filename; that patch is attached.

Note that in Mint 17, it seems that /etc/grub.d/10_linux is overwritten on every boot by /usr/share/ubuntu-system-adjustments/grub/10_linux. This is where I've applied my patch.

My guess is that the optimal solution is probably to move closer to upstream Ubuntu's current grub configuration system, which seems to have solved this problem, but in some different or more elaborate way than I did, rather than adopting my patch and further diverging Mint from upstream? But I'm new here and just guessing at what the community would consider most appropriate or desirable. Happy to help in whatever way, to get this fixed!

[Timothée Manaud (timothee)]

Selecting "Previous Linux Version" in GRUB menu and the second "Linux Mint 17... recover" did the trick for me.
Hope it will be fixed.

[Mike (m-launchpad-net-s)]

I ran into this issue; my root is an LVM2 volume. I manually applied David's patch (from #1) and update-grub correctly generated the signed initrd images and I was able to boot.

[Pablo Castellano (pablocastellano)]

Same here, workaround from #1 worked like a charm.

[Kcho Lorenzetti (kcholoren)]

Comment #1 worked perfectly ... why this is not included in the distribution?

[Adam (adam-stephens)]

There's nothing quite as sad as finding a bug that breaks an OS completely, and is obviously going to affect a lot of people, and seeing that a customer has solved it, taken the time to write and submit a clear bug report with a patch, and it's just sat unassigned in the bug tracker for a whole year.

Presumably most of the people affected have installed mint, upgraded the system, discovered it doesn't boot any more and just ditched it for something that works.

[Clement Lefebvre (clementlefebvre)]

Thanks for this workaround.

This should be fixed as of Mint 18.2.