Bug#706561: grub2: removes EFI boot entry 'debian' every time grub-install is used

[Steve McIntyre]

On Wed, May 01, 2013 at 05:30:46PM +0100, Jonathan Wiltshire wrote:
>Source: grub2
>Version: 1.99-27
>Severity: important
>Tags: d-i
>
>grub-install removes and then re-instates the 'debian' boot entry every
>time it runs. If it can't be re-instated, no indication is given to the user
>that the system will no longer boot.
>
>This was revealed on my 
>  	Manufacturer: ASRock
>	Product Name: H61M-ITX
>when I installed an updated grub package, and it updated the bootloader. It
>seems part of the EFI storage was too full, and since garbage collection does
>not take place until boot time, a boot entry could not be added. (It's also
>possible that storage was not full, and this is really a firmware bug.)
>
>In this situation grub-install still emits "Installation finished. No error
>reported" and exits 0. This is misleading.
>
>For my particular machine, just one invocation of grub-install was enough to
>trigger this bug.
>
>Recovering involves booting from a Wheezy install CD (which also triggers EFI
>garbage collection), loading the efivars module, and running grub-install
>followed by a reboot. 
>
>This has implications for stable updates of grub during the lifetime of
>Wheezy.
>
>If grub-install detects that there is no need to remove and re-instate the
>boot entry, it should not do so. If there is a need, and it fails for any
>reason, the script should warn the user very loudly indeed and exit non-0.

I've already worked with Jonathan to help debug this problem, and I
have a proposed patch for grub-install which will improve things
here. I don't claim to totally fix the problem (as I don't think it's
soluble in the general case), but I think it helps.

Currently, the code does:

 * delete all existing boot entries for this $vendor
 * create a new boot entry

It also does not attempt to verify that the entry was actually created
correctly, which is unfortunate.

I've updated this to do:

 * check to see how many boot entries exist for this $vendor. If there
   is exactly one, then see if we might be able to re-use it:

   + checksum the existing entry
   + create a testing entry in a temp file and checksum it
   + if the checksums match, exit - no need to change anything

 * if there are no existing boot entries, or more than 1, fall back to
   (almost) existing behaviour:

   + delete any entrie
   + create a new one
   + (new behaviour) check with efibootmgr that the new entry has
     actually been written. If not, abort appropriately.

Patch is attached. It works fine for me on my EFI system, coping with
various situations. As I can't reproduce the original problem myself,
Jonathan also tested this and confirmed that it helped.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews
-------------- next part --------------
A non-text attachment was scrubbed...
Name: grub-efi-reinstall.diff
Type: text/x-diff
Size: 5097 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20130501/fff05a9b/attachment.diff>