Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})

[Ian Campbell]

On Tue, 2014-12-30 at 21:32 +0100, Axel Angel wrote:
> @@ -7511,7 +7511,6 @@
>  grub-install: info: executing efibootmgr --version </dev/null >/dev/null.
>  grub-install: info: executing modprobe -q efivars.
>  grub-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L debian -l \EFI\debian\grubx64.efi.
> -
> -Could not prepare boot variable: No such file or directory
> -
> +efibootmgr: Could not set variable Boot0000: No such file or directory
> +efibootmgr: Could not prepare boot variable: No such file or directory
>  Installation finished. No error reported.

Was this in the state where things crashed or the "working" state (but
with the second issue you mentioned occurring)?

[...]
> So, I tried many things and found that indeed the new version is not the
> source of the problem. In fact the system before the upgrade exhibits the
> same problem under a simple condition: when the system was resumed from
> disk. I found that everything is fine when it is freshly booted,
> whichever the version -18 or -19.

I think there is a pretty good chance that this is therefore a firmware
issue. I'd recommend the first thing to try would be to see if an
updated firmware is available for your system and if so then install it.

Your kernel stack trace shows that the CPU has tried to execute code
from a region of RAM which has been marked non-executable when calling
into the firmware. I'm not familiar enough with EFI to know if
responsibility for this lies with the firmware or the kernel and have a
feeling it might be the two in concert.

You might find that adding "noexec=off" to your kernel command line
worksaround this issue.

> I upgraded all the package again and reproduced my problem with -19.
> I have the kernel log when it crashed but not the log of grub-install
> because it froze immediately this time, I couldn't save it. I have a
> photo of the last lines nonetheless, that may help.
> 
> Moreover it has been since a few months that efibootmgr didn't work
> properly for my motherboard. I noticed that since it broke, efibootmgr
> deletes every boot entries, moreover its own is not visible afterward. I
> had to place the grub binary myself into the generic location
> "/boot/efi/EFI/BOOT/BOOTx64.efi" to make my system boots, and it works.

Sounds like a firmware issue to me, if an upgrade doesn't help I'd
recommend to start by reporting against efibootmgr.

> I own a thinkpad x220 and indeed I don't suffer these problems. That
> means either one of these: as you said the firmware is bugged or the
> support for my MB is not fully complete.
> 
> I am no expert on the matter, if you have any clue whether I should
> report it to an other package like efibootmgr or how can I find more
> informations?

Once you've updated the firmware I think I'd suggest starting by
reassigning this crash issue to the Linux package (I can help with the
mechanics of that if you need). The thing about the delete boot entries
probably ought to start with efibootmgr (I could clone this report, but
I think a fresh one dedicated to that issue would be better).

Ian.