On Tue, Nov 28, 2023 at 9:45 AM Pascal Hambourg <[email protected]> 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).
