Your message dated Sat, 23 Mar 2019 11:02:37 +0000
with message-id <[email protected]>
and subject line Re: Bug#706561: grub2: removes EFI boot entry 'debian' every
time grub-install is used
has caused the Debian Bug report #706561,
regarding grub2: removes EFI boot entry 'debian' every time grub-install is used
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
706561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706561
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Source: grub2
Source-Version: 2.02+dfsg1-15
On Wed, May 01, 2013 at 06:15:41PM +0100, Steve McIntyre wrote:
> 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.
Fixed in a somewhat different way (necessarily different due to
substantial changes in both grub-install and efibootmgr) in
2.02+dfsg1-15:
grub2 (2.02+dfsg1-15) unstable; urgency=medium
* Build-depend on libefiboot-dev and libefivar-dev, for EFI variable
storage changes.
* Drop now-unnecessary dependencies on efibootmgr.
-- Colin Watson <[email protected]> Sat, 23 Mar 2019 09:56:35 +0000
grub2 (2.02+dfsg1-14) unstable; urgency=medium
* Make signed packages depend on a matching version of grub-common, in an
attempt to prevent incorrect testing migrations (closes: #924814).
* Cherry-pick from upstream:
- xfs: Accept filesystem with sparse inodes (closes: #924760).
* Minimise writes to EFI variable storage (closes: #891434).
-- Colin Watson <[email protected]> Sat, 23 Mar 2019 09:47:10 +0000
Thanks,
--
Colin Watson [[email protected]]
--- End Message ---
