Re: grub-install deleting long UEFI entries bug ?

[Andrei Borzenkov <arvidjaar@gmail.com>]

23.04.2017 23:33, adrian15 пишет:
> El 23/04/17 a las 10:45, Andrei Borzenkov escribió:
>> 23.04.2017 11:21, adrian15 adrian15 пишет:
>>> 2017-04-23 6:36 GMT+02:00 Andrei Borzenkov <arvidjaar@gmail.com>:
>>>
>>>> 23.04.2017 03:54, adrian15 пишет:
>>>>> grub-install seems to be deleting long UEFI entries
>>>>>
>>>>> (*) What the bug is
>>>>>
>>>>> * Add an UEFI entry with this label (Remove the single quotes):
>>>>>  '(Rescapp added) \EFI\ubuntu\MokManager.efi'
>>>>>
>>>>> Example:
>>>>>
>>>>> efibootmgr -c \
>>>>>  -d /dev/sda \
>>>>>  -p 2 \
>>>>>  -L '(Rescapp added) \EFI\ubuntu\MokManager.efi' \
>>>>>  -l '\EFI\ubuntu\MokManager.efi'
>>>>>
>>>>> * Run grub-install /dev/sda or maybe just grub-install
>>>>>
>>>>> I expect the newly added uefi entry to be there.
>>>>> What I find is that the entry has been lost or deleted!
>>>>>
>>>>
>>>> What is value of GRUB_DISTRIBUTOR in /etc/default/grub?
>>>>
>>>
>>> After evaluating the bash expression the GRUB_DISTRIBUTOR value is Ubuntu.
>>>
>>
>> Yes, historically grub did case insensitive substring search. This
>> probably is wrong, we should just take everything after boot number
>> literally.
> 
> I see, like removing what you are about to add I guess.
> The problem that I see is that efibootmgr output (even if --verbose
> switch) it's not machine readable.
> 

We are using plain "efibootmgr" without --verbose and output is variable
name followed by either '*' or space followed by space followed by
description if present. Unless description contains newline, it looks
straightforward to parse.

> I guess efibootmgr itself would need an specific switch in order to
> produce output suitable for scripts.

It would need somehow escape newline

> Another option is include some of
> the efibootmgr functionality/libraries into grub itself.
> 

Yes, I have half-done patch but as I see now it is probably not really
needed unless we actually have case of description containing newlines.

>>>
>>> 2) Then there's:
>>>
>>>       if (grub_memcmp (line, "Boot", sizeof ("Boot") - 1) != 0
>>>  || line[sizeof ("Boot") - 1] < '0'
>>>  || line[sizeof ("Boot") - 1] > '9')
>>> continue;
>>>
>>> which might be wrong because of 0 and 9 and maybe not because of the array
>>> indexes.
>>>
>>> Let's go into details about that.
>>>
>>> 2.1) Boot0000 First entry
>>> BootA000 Second entry
>>>
>>> Shouldn't the look for A to F hexadecimal letters too?
>>>
>>
>> Yes. Patches are welcome for both problems. Second one is actually bug
>> fix so should be independent.
>>
>>> And...
> 
> Well, I think just checking 0 to 9 in the first character is a good
> compromise.
> 
> Some outputs have: BootCurrent . So 'BootC' can be found in e.g.
> 'BootC001' too. So that would be adding another problem because
> 'BootCurrent' would be considered as a right entry.
> 

This simply means that we have to check for exactly 4 hexadecimal
numbers, not shortcut this.