On Thu, 25 Aug 2022 23:32:01 -0500 Glenn Washburn <developm...@efficientek.com> wrote:
> This series improves the EFI chainloader. I've noticed for a while > now that chainloading would fail when root=memdisk. It didn't really > make sense because I was specifying the image to chainload as > device+path, so why would it care about what my root was. But I > noticed that if I changed the root to the device the image file was > located on, then chainloading worked. The second patch fixes this by > removing some previous assumptions that I don't believe are valid > (eg. that LoadImage needs a valid device path). In a previous response to Dimitri Ledkov, I got confused as to what the DevicePath parameter to BootService.LoadImage was supposed to be. I was thinking it could be a kind of equivalent to the shell's current working directory. According to the spec 2.10 7.4.1, it is "the DeviceHandle specific file path from which the image is loaded." So really $root should have nothing to do with it, unless the chainloaded file is not specified with a leading device component. My conclusion is that the current implementation violates the spec. The right thing to do is to try to make a device path from the path of the chainloaded file. If a device path can not be made (eg. the file can not be accessed from the firmware) then the DevicePath parameter should be NULL, which is valid because the parameter is marked optional. So, Daniel, actually I think this patch does the right thing and is ready for review. Glenn > Glenn Washburn (2): > efi/chainloader: Do not require a valid $root when chainloading > docs: Document that extra arguments to chainloader on EFI > > docs/grub.texi | 7 +++++-- > grub-core/loader/efi/chainloader.c | 31 > +++++++++++------------------- 2 files changed, 16 insertions(+), 22 > deletions(-) > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
