grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Make grub-install check for errors from efibootmgr


From: Steve McIntyre
Subject: Re: [PATCH] Make grub-install check for errors from efibootmgr
Date: Thu, 9 Feb 2017 20:37:11 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Feb 09, 2017 at 09:52:40PM +0300, Andrei Borzenkov wrote:
>30.01.2017 22:04, Steve McIntyre пишет:
>> Code is currently ignoring errors from efibootmgr, giving users
>> clearly bogus output like:
>> 
>>         Setting up grub-efi-amd64 (2.02~beta3-4) ...
>>         Installing for x86_64-efi platform.
>>         Could not delete variable: No space left on device
>>         Could not prepare Boot variable: No space left on device
>>         Installation finished. No error reported.
>> 
>> and then potentially unbootable systems. If efibootmgr fails,
>> grub-install should know that and report it!
>
>This looks more or less cosmetic to me. First, errors are displayed to
>user so it is not that user is not aware.

Maybe, maybe not - if this occurs in the middle of a set of package
installations or upgrades on a system, text like this will get lost.

>Second, efibootmgr is more or less optional. This is convenient but
>by far not the only one possibility to use newly installed
>grub.

If you're running on a UEFI system, this is anything *but* optional.

>Third, even successful execution of efibootmgr does not mean it will
>actually boot grub - there are enough systems out there that will
>simply ditch grub entry and replace it with hard coded Windows one.

That's not an excuse for not catching errors on systems that *are*
working.

>So I'm fine with changing "no error reported" to "efibootmgr invocation
>failed; check your firmware settings" or similar, but I am not sure we
>need to abort grub-install in this case. What exact problem do you solve
>by aborting?

You pick up an error correctly, and report it upwards so that other
programs calling grub-install can reliably check for errors, and maybe
deal with those errors.

I don't see why it's a problem to actually handle errors properly?

In Debian we're seeing quite a few people reporting problems in this
area. It would be better to catch and handle errors better here. See
https://bugs.debian.org/852513 for an example.

-- 
Steve McIntyre, Cambridge, UK.                                address@hidden
You raise the blade, you make the change... You re-arrange me 'til I'm sane...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]