Re: Chainloading an MS Windows installer DVD

[SteveSi]

Even if it did boot, Windows setup would not be able to find the
install.wim file which is inside the iso, so you would get a 'Missing
DVD/CD drive driver' message.
Most multiboot solutions which boot windows ISO files, use a pxe wimboot
grub2 module. So the boot.wim file is loaded from the loopback iso grub2
device and it then boots to winpe.
Files are also injected into the boot ram image which then loads the iso
file as a virtual dvd so that setup will see the install.wim file on a
mounted volume.


On Mon, 23 Oct 2023, 20:23 Andrei Borzenkov, <arvidjaar@gmail.com> wrote:

> On 23.10.2023 11:58, Philip Couling wrote:
> > Really I've been as precise as I can and given everything I've seen.  It
> > was actually the minimalist output that prompted me to come ask. Yes that
> > was all of the output.
> >
> > I'll investigate further if that points to an error on my part. I assume
> > setting root=... is enough to set the device path. But to be clear: no,
> the
> > only output from the chainloader command was "/EndEntire".
> >
>
> It implies that $root could not be opened or is empty. I cannot
> reproduce it with openSUSE Tumbleweed grub2, but that is because as I
> mentioned it is heavily patched and is always using the device from the
> chainloader argument.
>
> > I didn't realise distributions had customised grub in that way. I'm using
> > the Ubuntu (22.04) release. If you think that may be a problem I can
> retry
> > with upstream version.
> >
>
> I do not know what changed are in Ubuntu.
>
> > If you know of a way to get more debug info out of the chainloader or
> > command boot command because I was really hoping for more than "Unknown
> > Error" too!
> >
>
> Not without recompiling grub.
>
> Anyway, my best guess is that Windows primary bootloader fails to find
> (or read) its CD. grub2 plays some tricks with EFI CD device paths. So
> device path that it associated with loaded image is not CD media device
> path, but (parent) block device path. It is quite possible that Windows
> loader is not prepared to handle it. As a simple example - EFI CD media
> handle has simple file protocol that allows reading it; while block
> device does not have it.
>
> I tried to boot cdboot.efi instead and I get "Press and key to boot from
> CD ..." and then it fails as well which sort of confirms my guess (that
> loaded image is started but fails).
>
> If my guess is correct, I right now do not see how to make it work.
> grub2 simply does not expose media CD path (which points to the
> underlying EFI "system partition" boot image on CD).
>
> > On Mon, 23 Oct 2023 at 08:25, Andrei Borzenkov <arvidjaar@gmail.com>
> wrote:
> >
> >> On Thu, Oct 19, 2023 at 12:36 PM Philip Couling <couling@gmail.com>
> wrote:
> >>>
> >>> Hi
> >>>
> >>> Is there any reason why I can't chainload an MS Windows Installer (on
> >>> USB)?  Currently when I try this I get "UnknownError" when I type
> "boot"
> >> at
> >>> the grub command line.
> >>>
> >>> The MS Windows ISOs are a bit weird: found here:
> >>> https://www.microsoft.com/en-gb/software-download/windows10ISO
> >>>
> >>> They are not partitioned and have a UDF filesystem instead of ISO 9660
> or
> >>> FAT32. So my hardware cannot directly boot this.  But I was assuming
> that
> >>> all I would need to do would be ask grub to chainload the ISO as it
> has a
> >>> UDF driver.
> >>>
> >>> I can read the Windows Boot media after I "insmod udf" and then
> >>> "chainloader /efi/boot/bootx64.efi" which results in the output
> >>> "/EndEntire".
> >>
> >> Is it really *all* that is printed? Because grub should print the
> >> device path and it sounds like it is empty? Always provide complete
> >> and accurate information, not some random part of it. At the very
> >> least there should be "file path: " somewhere before "/EndEntire".
> >>
> >>> But when I then type "boot" I get "UnknownError".
> >>>
> >>
> >> grub should really print the EFI error in this case to help in
> >> troubleshooting such issues.
> >>
> >>> Has anyone experienced this? Any ideas about what isn't working? I
> freely
> >>
> >> Assuming you are using the current upstream code (because in the past
> >> EFI chainloader was heavily patched by distributions) grub reads the
> >> content of EFI binary in memory, creates an instance of loaded image
> >> from it and then calls EFI start image function. I would refrain from
> >> guessing what could have gone wrong until you provide more precise
> >> information.
> >>
> >>> admit it could be a Microsoft weirdness that requires their input, I
> just
> >>> wanted to exhaust options here first.
> >>>
> >>> Thanks
> >>
> >
>
>
>