Your message dated Sat, 23 Mar 2019 09:57:20 +
with message-id
and subject line Bug#891434: fixed in grub2 2.02+dfsg1-14
has caused the Debian Bug report #891434,
regarding grub-efi: System fails to boot after "No space left on device" on EFI
variable storage
to be marked as d
Control: tag -1 pending
Hello,
Bug #891434 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/grub-team/grub/commit
Processing control commands:
> tag -1 pending
Bug #891434 [src:grub2] grub-efi: System fails to boot after "No space left on
device" on EFI variable storage
Bug #923839 [src:grub2] efibootmgr should only be called if changes are needed
Added tag(s) pending.
Added tag(s) pending
On Sun, 10 Mar 2019 21:57:02 + Colin Watson wrote:
> Control: reassign 891434 src:grub2
> Control: forcemerge 891434 923839
>
> On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote:
> > But I'm reassigning this bug to grub2, because I think the right answer for
> > nearly all efiboo
Control: reassign 891434 src:grub2
Control: forcemerge 891434 923839
On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote:
> But I'm reassigning this bug to grub2, because I think the right answer for
> nearly all efibootmgr write failures on update of the bootloader packages is
> that g
On Fri, 14 Dec 2018 10:22:49 +0100 Ralf Jung wrote:
> Hi,
>
> > Fixing this does seem like it would be a good idea for general
> > robustness against dodgy firmware (this is not the first iteration of
> > problems along these lines). It would take some development work, but
> > hopefully not too
Hi,
> Fixing this does seem like it would be a good idea for general
> robustness against dodgy firmware (this is not the first iteration of
> problems along these lines). It would take some development work, but
> hopefully not too much.
>
> Things that GRUB can't do, as far as I can tell:
>
>
On Sun, Feb 25, 2018 at 04:13:13PM +0100, Ralf Jung wrote:
> earlier today I did a system update, which completed successfully (as in, dpkg
> didn't stop due to an error). I then rebooted my machine. This left Linux
> unable to boot; only the Windows entry was left in the boot menu. After some
>
Just had this again, this time even after I repaired Debian, Windows disappeared
completely from the start menu. I do not yet know how to get it back.
What does it take to get attention t a bug that completely breaks the system?
Kind regards,
Ralf
Package: grub-efi-amd64
Version: 2.02+dfsg1-4
Followup-For: Bug #891434
I just ran into this same issue and it is specific to grub:
refind-install also has similar issues, so this is specific to the state of the
computer.
I found this answer helpful:
https://unix.stackexchange.com/a/379824
On Wed, 07 Mar 2018 11:13:02 -0500 Rann Bar-On wrote:
> Is this still the case with 2.02+dfsg1-3 or has it been fixed?
Yes, it is.
I experinced the same issue on 2 Acer Aspire V13 PC's.
Updating GRUB to 2.02+dfsg1-2 and to 2.02+dfsg1-3.
Both PC's left unbootable.
Rescued with an install image
Is this still the case with 2.02+dfsg1-3 or has it been fixed?
Hi,
I experienced the same today after a grub update to '2.02+dfsg1-1' on testing.
Looking back at logs, grub-install reported an error but the upgrade process
as a whole didn't fail, so I missed it at first:
```
Could not prepare Boot variable: No space left on device
grub-install: error: efibootm
Package: grub-efi
Version: 2.02+dfsg1-1
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
earlier today I did a system update, which completed successfully (as in, dpkg
didn't stop due to an error). I then rebooted my machine. This left Linux
unable to boot; only the Wi
14 matches
Mail list logo