Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boot Windows directly from the ISO #4

Closed
a1ive opened this issue Oct 23, 2021 · 18 comments
Closed

Boot Windows directly from the ISO #4

a1ive opened this issue Oct 23, 2021 · 18 comments
Labels
enhancement New feature or request

Comments

@a1ive
Copy link

a1ive commented Oct 23, 2021

Nice project.
I see on windows_support.md that it says

Currently, you have to extract the files from the ISO image. In the future, we plan to run Windows directly from the ISO image.

How are you going to implement it? Any good ideas? I might be able to help you.

@Mexit
Copy link
Owner

Mexit commented Oct 24, 2021

I was thinking of wimboot and pure grub2 with patches (wimboot, secure boot etc).
I would be very happy if you have any information, tips.

@a1ive
Copy link
Author

a1ive commented Oct 24, 2021

I was thinking of wimboot and pure grub2 with patches (wimboot, secure boot etc).

We need to patch to either GRUB2 or wimboot.
I've noticed that you are using OpenSUSE fork of GRUB2. If we add additional patches to it, it may conflict with future OpenSUSE commits.
As for wimboot, this won't cause too much trouble as it has a relatively small amount of code.

@Mexit
Copy link
Owner

Mexit commented Oct 24, 2021

I've noticed that you are using OpenSUSE fork of GRUB2.

I am currently using grub2 from Ubuntu. The one from openSUSE is just a source code repo.

It is more complicated than I thought. I need some time to familiarise myself with it all.

@Mexit Mexit added the enhancement New feature or request label Dec 6, 2021
@a1ive
Copy link
Author

a1ive commented Feb 27, 2022

I have ported wimboot to gnu grub 2.06 (x86_64-efi), and grub2-ubuntu may work without modification.
wimboot.tar.gz
wimboot.tar.gz
mv wimboot.tar.gz grub-core/
tar -xf wimboot.tar.gz
then edit grub-core/Makefile.core.def, and add the following content:

module = {
  name = wimboot;
  common = wimboot/main.c;
  efi = wimboot/efiboot.c;
  common = wimboot/huffman.c;
  common = wimboot/lzx.c;
  common = wimboot/vdisk.c;
  common = wimboot/wim.c;
  common = wimboot/wimfile.c;
  common = wimboot/wimpatch.c;
  common = wimboot/xpress.c;
  enable = x86_64_efi;
  enable = i386_efi;
  cflags = '-fshort-wchar';
  cppflags = '-I$(srcdir)/wimboot';
};

usage:

menuentry "wimboot" {
  wimboot @boot.wim=/wim/pe.wim \
          @bootmgfw.efi=/wim/bootmgfw.efi \
          @bcd=/wim/bcd \
          @boot.sdi=/wim/boot.sdi
}

@Mexit
Copy link
Owner

Mexit commented Mar 1, 2022

Thank you very much. I will test it in the coming days.

@a1ive
Copy link
Author

a1ive commented Mar 31, 2022

@Mexit any comments on my solution?

@Mexit
Copy link
Owner

Mexit commented Apr 3, 2022

any comments on my solution?

It works!

At this moment I tested your solution with GRUB without any modifications.

Can your solution work in the BIOS version as well?

@a1ive
Copy link
Author

a1ive commented Apr 4, 2022

Can your solution work in the BIOS version as well?

No. We can only use linux16 /wimboot; initrd16 ....

@Mexit
Copy link
Owner

Mexit commented Feb 8, 2024

I have returned to the subject of wimboot.... Not enough time...
In the meantime, I swapped ubuntu grub for the original grub 2.12.
I am currently actively testing your solution. However, it only works to commit bb4aa6e06.
From commit df16fe97b it no longer compiles because the call wrappers have been removed.

Is there still any chance in this case to add wimboot to grub 2.12?

Another problem I've encountered is with the latest Win11_23H2_English_x64v2.iso: loading files ends with the message: "cannot load image".

//efiboot.c
if (status != GRUB_EFI_SUCCESS)
    grub_fatal("cannot load image\n");

@a1ive
Copy link
Author

a1ive commented Feb 9, 2024

I have returned to the subject of wimboot.... Not enough time... In the meantime, I swapped ubuntu grub for the original grub 2.12. I am currently actively testing your solution. However, it only works to commit bb4aa6e06. From commit df16fe97b it no longer compiles because the call wrappers have been removed.

Is there still any chance in this case to add wimboot to grub 2.12?

Another problem I've encountered is with the latest Win11_23H2_English_x64v2.iso: loading files ends with the message: "cannot load image".

//efiboot.c
if (status != GRUB_EFI_SUCCESS)
    grub_fatal("cannot load image\n");

GRUB 2.12 has added support for loading initrd using the LoadFile2 protocol on x86 platforms, so you can patch wimboot and boot it.
I have submitted the PR to the wimboot project, but have not gotten a response: ipxe/wimboot#49

@Mexit
Copy link
Owner

Mexit commented Feb 9, 2024

Excellent work a1ive!
I did the tests. It works flawlessly. However, there is a problem after enabling SB - it gives me an error:
couldn't find suitable memory target.
The same thing happens on the original wimboot, both with SB enabled and disabled.

@a1ive
Copy link
Author

a1ive commented Feb 9, 2024

Excellent work a1ive! I did the tests. It works flawlessly. However, there is a problem after enabling SB - it gives me an error: couldn't find suitable memory target. The same thing happens on the original wimboot, both with SB enabled and disabled.

This is related to the UEFI memory mapping. If you're using a virtual machine, please increase the allocated memory.

@Mexit
Copy link
Owner

Mexit commented Feb 9, 2024

please increase the allocated memory

I've thought about that too. Unfortunately it doesn't help.
I checked on VM and physical hardware. This error only occurs when SB is enabled. When turned off, everything works fine.

It may be a bug in GRUB. I found the code fragment responsible for this:

#ifdef GRUB_MACHINE_EFI
    grub_efi_mmap_iterate (grub_relocator_alloc_chunk_align_iter, &ctx,
			   avoid_efi_boot_services);
#elif defined (__powerpc__) || defined (GRUB_MACHINE_XEN)
    (void) avoid_efi_boot_services;
    grub_machine_mmap_iterate (grub_relocator_alloc_chunk_align_iter, &ctx);
#else
    (void) avoid_efi_boot_services;
    grub_mmap_iterate (grub_relocator_alloc_chunk_align_iter, &ctx);
#endif
    if (!ctx.found)
      return grub_error (GRUB_ERR_BAD_OS, "couldn't find suitable memory target");
  }

@Mexit
Copy link
Owner

Mexit commented Feb 9, 2024

I was able to extract some information from the boot process.
If SB is enabled, the booting is completely different - no information that it uses the LoadFile2 protocol.

#################
#  SB disabled  #
#################

loader/efi/linux.c:102:linux: UEFI stub kernel:
loader/efi/linux.c:103:linux: PE/COFF header @ 00000040
loader/efi/linux.c:132:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:515:linux: kernel file size: 59776
loader/efi/linux.c:517:linux: kernel numpages: 15
loader/efi/linux.c:534:linux: kernel @ 0x7e1d2000
loader/efi/linux.c:420:linux: Using LoadFile2 initrd loading protocol
loader/efi/linux.c:217:linux: linux command line:
'BOOT_IMAGE=/MultiOS-USB/tools/wimboot-2.7.6-a1ive/wimboot gui'
loader/efi/linux.c:237:linux: starting image 0x7e8f4318


wimboot v2.7.6 -- Windows Imaging Format bootloader -- https://ipxe.org/wimboot

Command line: "BOOT_IMAGE=/MultiOS-USB/tools/wimboot-2.7.6-a1ive/wimboot gui"
...found initrd media device
loader/efi/linux.c:360:linux: Providing initrd via EFI_LOAD_FILE2_PROTOCOL
loader/linux.c:68:linux: newc: Creating path 'bootx64.efi', mode=0100777,
size=1692144
loader/linux.c:68:linux: newc: Creating path 'bcd', mode=0100777, size=16384
loader/linux.c:68:linux: newc: Creating path 'boot.sdi', mode=0100777,
size=3170304
loader/linux.c:68:linux: newc: Creating path 'boot.wim', mode=0100777,
size=533364998
loader/linux.c:68:linux: newc: Creating path 'TRAILER!!!', mode=0, size=0
Using bootx64.efi via 0x59e6e07c len 0x19d1f0
...found bootmgfw.efi file bootx64.efi
Using bcd via 0x5a00b2e0 len 0x4000
...found BCD
Using boot.sdi via 0x5a00f358 len 0x306000
Using boot.wim via 0x5a3153d0 len 0x1fca8106
...found WIM file boot.wim
...patching WIM boot.wim
...patching WIM header at [0x0,0xd0)
...found file "\Windows\Boot\Fonts\segmono_boot.ttf"
Using segmono_boot.ttf via 0x7db85060 len 0xb2f4
...found file "\Windows\Boot\Fonts\segoen_slboot.ttf"
Using segoen_slboot.ttf via 0x7db85150 len 0x1910c
...found file "\Windows\Boot\Fonts\segoe_slboot.ttf"
Using segoe_slboot.ttf via 0x7db85240 len 0x19220
...found file "\Windows\Boot\Fonts\wgl4_boot.ttf"
Using wgl4_boot.ttf via 0x7db85330 len 0xc37c
Read bootx64.efi
Loaded bootx64.efi

#################
###  Windows  ###
#################
################
#  SB enabled  #
################

loader/efi/linux.c:468:linux: shim_lock enabled, falling back to legacy Linux
kernel loader
lib/relocator.c:114:relocator: relocators_size=12
lib/relocator.c:1252:relocator: min_addr = 0x0, max_addr = 0xffffffffffffffff,
target = 0x100000
lib/relocator.c:431:relocator: trying to allocate in
0x100000-0xffffffffffffffff aligned 0x1 size 0xe000
lib/relocator.c:1201:relocator: allocated: 0x100000+0xe000
lib/relocator.c:1290:relocator: allocated 0x100000/0x100000
lib/relocator.c:1308:relocator: relocators_size=12
lib/relocator.c:1316:relocator: relocators_size=12
lib/relocator.c:1323:relocator: cur = 0x79b7ee00, next = 0x0
loader/i386/linux.c:204:linux: prot_mode_mem = 0x100000, prot_mode_target =
100000, prot_size = e000
loader/i386/linux.c:870:linux: bzImage, setup=0x800, size=0xdf80
loader/i386/linux.c:1111:linux: Initrd at addr 0x17e9f000 which is expected in
ranger 0x12a000 ~ 0x37feffff
lib/relocator.c:1401:relocator: chunks = 0x79b7ee00
lib/relocator.c:431:relocator: trying to allocate in 0x12a000-0x17e9f000
aligned 0x1000 size 0x20150000
lib/relocator.c:1425:relocator: Adjusted limits from 12a000-17e9f000 to
10e000-ffffffffffffffff
lib/relocator.c:431:relocator: trying to allocate in
0x10e000-0xffffffffffffffff aligned 0x1000 size 0x20150000
lib/relocator.c:1201:relocator: allocated: 0x1500000+0x20150000
lib/relocator.c:1481:relocator: relocators_size=12
lib/relocator.c:1489:relocator: relocators_size=12
lib/relocator.c:1495:relocator: cur = 0x7a72ce20, next = 0x79b7ee00
loader/linux.c:68:linux: newc: Creating path 'bootx64.efi', mode=0100777,
size=1692144
loader/linux.c:68:linux: newc: Creating path 'bcd', mode=0100777, size=16384
loader/linux.c:68:linux: newc: Creating path 'boot.sdi', mode=0100777,
size=3170304
loader/linux.c:68:linux: newc: Creating path 'boot.wim', mode=0100777,
size=533364998
loader/linux.c:68:linux: newc: Creating path 'TRAILER!!!', mode=0, size=0
loader/i386/linux.c:1138:linux: Initrd (0x1500000) at 0x1500000,
size=0x2014f554
video/efi_gop.c:388:video: GOP: keeping mode 12
video/efi_gop.c:493:video: GOP: initialising FB @ 0xc0000000 1280x800x32
video/efi_gop.c:520:video: GOP: Success
loader/i386/linux.c:531:linux: real_size = 4000, mmap_size = 2000
loader/i386/linux.c:379:linux: addr = 10000, size = 20000, need_size = 7000
loader/i386/linux.c:379:linux: addr = 50000, size = 37000, need_size = 7000
loader/i386/linux.c:379:linux: addr = 88000, size = 8000, need_size = 7000
loader/i386/linux.c:541:linux: real_mode_target = 89000, real_size = 4000,
efi_mmap_size = 3000
lib/relocator.c:1252:relocator: min_addr = 0x0, max_addr = 0x100000, target =
0x89000
lib/relocator.c:431:relocator: trying to allocate in
0x10e000-0xffffffffffffffff aligned 0x1 size 0x7000
lib/relocator.c:1201:relocator: allocated: 0x7ef8b000+0x7000
lib/relocator.c:1290:relocator: allocated 0x7ef8b000/0x89000
lib/relocator.c:1308:relocator: relocators_size=12
lib/relocator.c:1316:relocator: relocators_size=51
lib/relocator.c:1323:relocator: cur = 0x78310e60, next = 0x7a72ce20
loader/i386/linux.c:564:linux: real_mode_mem = 0x7ef8b000
loader/i386/linux.c:574:linux: code32_start = 0
kern/efi/sb.c:121:efi: UEFI Secure Boot state: Enabled

#################
###  Restart  ###
#################

@a1ive
Copy link
Author

a1ive commented Feb 10, 2024

I was able to extract some information from the boot process. If SB is enabled, the booting is completely different - no information that it uses the LoadFile2 protocol.

You are right. GRUB 2 won't use LoadFile2 if shim is enabled.
https://github.com/rhboot/grub2/blob/9e1b18fc17b623446c1adf0466158c7cf7a58303/grub-core/loader/efi/linux.c#L465
We should remove this check and sign the wimboot image.

@Mexit
Copy link
Owner

Mexit commented Feb 13, 2024

We should remove this check and sign the wimboot image.

It almost worked:

loader/efi/linux.c:102:linux: UEFI stub kernel:
loader/efi/linux.c:103:linux: PE/COFF header @ 00000040
loader/efi/linux.c:132:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:504:linux: kernel file size: 59776
loader/efi/linux.c:506:linux: kernel numpages: 15
loader/efi/linux.c:523:linux: kernel @ 0x7d12a000
loader/efi/linux.c:420:linux: Using LoadFile2 initrd loading protocol

#############################
###  Return to grub menu  ###
#############################

@a1ive
Copy link
Author

a1ive commented Feb 17, 2024

We should remove this check and sign the wimboot image.

It almost worked:

loader/efi/linux.c:102:linux: UEFI stub kernel:
loader/efi/linux.c:103:linux: PE/COFF header @ 00000040
loader/efi/linux.c:132:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:504:linux: kernel file size: 59776
loader/efi/linux.c:506:linux: kernel numpages: 15
loader/efi/linux.c:523:linux: kernel @ 0x7d12a000
loader/efi/linux.c:420:linux: Using LoadFile2 initrd loading protocol

#############################
###  Return to grub menu  ###
#############################

rhboot/grub2@6425c12

The LoadImage() provided by the shim does not consult MOK when loading
an image. So, simply signature verification fails when it should not.
This means we cannot use Linux EFI stub to start the kernel when the
shim is loaded.

Mexit added a commit that referenced this issue Feb 26, 2024
UEFI: Secure Boot must be disabled during installation:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6425c12cd77ad51ad24be84c092aefacf0875089

Windows ISO images are larger than 4GB, please use exFAT instead of fat32 when installing MultiOS-USB.

If you want to install Win11 on unsupported hardware, you can manually apply the attached registry
entries before starting the installation.
@a1ive a1ive closed this as completed Mar 1, 2024
@Mexit
Copy link
Owner

Mexit commented Mar 1, 2024

@a1ive
Thanks for your help, valuable tips and wimboot patches!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants