Re: Unexpected prefix value

[Andrei Borzenkov]

On Tue, Nov 28, 2023 at 9:45 AM Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
> On 28/11/2023 at 04:44, Andrei Borzenkov wrote:
> > On 27.11.2023 23:06, Pascal Hambourg wrote:
> >>
> >> But if I build an EFI GRUB core image with
> >>
> >>    grub-mkimage --prefix='(hd0,gpt4)' --format=x86_64-efi \
> >>     --output=/boot/efi/EFI/azerty/core.efi part_gpt ext2
> >>
> >> (no / at the end of prefix), then when booting it, the $prefix value
> >> seems to be the combination of the --prefix device and the $cmdpath path:
> >>
> >>    cmdpath=(hd0,gpt1)/EFI/azerty
> >>    prefix=(hd0,gpt4)/EFI/azerty
> >>
> >> Is this expected behaviour ?
> >
> > Yes. $prefix consists of two parts - device and the directory path. If
> > one of them is missing during initialization, grub attempts to guess and
> > fill it in.
>
> Guessing a missing or incomplete device makes sense, but what is the use
> case for guessing a missing path when the device is present ? AFAICS if
> the devices in $cmdpath and --prefix do not match, the resulting $prefix
> is doomed to failure.
>

I do not think it is done on purpose, it is more - garbage in, garbage
out. The file name without the path component is invalid, grub cannot
use it anyway. So it should either drop the value passed in --prefix
or do something to make it usable. I suppose, ignoring the value in
--prefix in this case would be more logical (of course, in this case
it should also check for the valid name in grub-mkimage as well to
avoid passing known garbage in the first place).