wimboot
wimboot copied to clipboard
ipxe
ARM Windows boot
Description
As a user, I would like to be able to boot ARM versions of Windows via wimboot, so that I can take advantage of HTTP boot.
Acceptance criteria
- [ ] ~~Ability to boot into some version of Windows on 32-bit ARM via qemu+OVMF+iPXE+wimboot~~
- [x] Ability to boot into some version of Windows on 64-bit ARM via qemu+OVMF+iPXE+wimboot
Dependencies
- #3
No changes for ARM has been made, Label not chagned.
Also see #3 which is blocking this
No changes for ARM has been made, Label not chagned
Thanks, will it be supported in 2.8.0? Appreciate if any schedule/plan.
I see the recent commits for ARM64 support, does anyone have any instructions on how I can build this on my own?
I see the recent commits for ARM64 support, does anyone have any instructions on how I can build this on my own?
Just type make and you'll get both the x86 and AArch64 versions built. You will need to install an appropriate cross-compiling gcc (or use clang).
Thanks I will try that. Curious if you will be publishing a new release that includes arm64 binaries?
Yes, the next release will include the arm64 binaries.
I've been delaying the release since the ARM portion is not yet covered by the automated testing, and I was hoping to get that done first. That said, the automated testing part is likely to be cumbersome to get working since the state of ARM virtualization is very immature compared to x86: there are multiple bugs and quirks that make it difficult to spin up an ARM Windows VM that can actually get as far as running the OS. The only combination I've found so that that works is to build EDK2's SbsaQemu firmware from source and use it in a sbsa-ref QEMU virtual machine to boot an MSDN-downloaded Windows 10 (not 11) image.
I may end up making a release that includes the ARM binaries without them being covered by the automated testing support, but I'd prefer to avoid that if possible.
I try to boot winpe in oracle aarch64 server.
- create arm64 winpe iso
- use dism to add virtio driver
- chain ipxe script
#!ipxe
kernel http://IP:PORT/wimboot.arm64
initrd http://IP:PORT/bootmgr.efi bootmgr.efi
initrd http://IP:PORT/Boot/boot.sdi boot.sdi
initrd http://IP:PORT/EFI/Microsoft/Boot/BCD BCD
initrd http://IP:PORT/sources/boot.wim boot.wim
boot
The final message is Forcing text mode output then Loading files....
However, the gui screen of winpe didn't show up and VNC console just show "Guest disabled display"
I use the same way to boot x86-64 winpe and succeed.
I try to boot winpe in oracle aarch64 server.
It sounds as though you're trying to boot Windows in a virtual machine. As mentioned above, getting Windows running in an ARM VM (independent of iPXE/wimboot) is irritatingly difficult. (For example: Windows requires the hypervisor and firmware to support a Secure World accessed via HVC, but this is not supported in most configurations of QEMU.)
Try getting Windows running at all first (e.g. try creating a bootable ISO), so that you know you have an ARM VM setup that is actually capable of running Windows first.
I'm trying to test this out on a Dell Inspiron 3420. It's an ARM64 Windows 11 laptop (Qualcomm Snapdragon processor).
Using pre-release 2.8.0
I get something similar to mlyxshi above. I have an identical ipxe script and when boot.wim loads I get some text that scrolls pretty fast so its hard to read but I see something similar, Forcing text mode output then Loading files... which does several progress bars then I see the Dell logo and the machine reboots.
If I take the exact same boot.wim and USB boot it works fine and I can boot into WinPE and it does an install.
Edit: I am not using any type of external display, only the builtin display in the laptop.
You can use pause to stop at the text gui to run the rest in full gui mode.
Only load wimboot kernel and the boot.wim, drop BCD, boot.sdi etc (these are extracted from boot.wim)
This will reduce the parameters that could be causing the reboot.
Thanks for the quick response. I played around with it some more last night and did try only loading wimboot and boot.wim but that didn't seem to change any thing. Also tried kernel wimboot pause
I also played around with Disabling automatic BCD modifications, Disabling automatic BCD modifications, Displaying graphical boot messages, found here: https://ipxe.org/wimboot#troubleshooting Nothing seemed to yield any better results.
Were there any differences between the pre-release 2.8.0 and the current release of 2.8.0?
The only difference between a prerelease and a release is that the release is signed for Secure Boot. Other than that, the binaries are identical (and are verified to be identical).
Thanks I appreciate it. Any recommendations for troubleshooting the issues I mention above?
Did you try gui command line?
Again, no BCD, no boot.sdi or other files.
Use the original boot.wim, unmodified, from the windows ISO.
Any modification, especially drivers, slipped into the wim is often causing issues, I tend to load drivers manually after completed boot.
Yes, I tried gui command line and also no BCD, no boot.sdi or other files. I'm trying to recall which boot.wim I tried previously... It did work via USB boot but not via PXE wimboot.
The hardware I'm working and testing on is the Dell Inspiron 3420 (Qualcomm)
There is the boot.wim that is included with the Dell recovery image that comes with all the necessary drivers integrated already (Windows 11 22H2 ARM64), I can USB boot this no problem.
There is also the boot.wim that is part of the Windows 11 23H2 ARM64 ISO provided by Microsoft VLC, this unfortunately does not include necessary drivers for the Dell Inspiron 3420 to boot as it lacks some Qualcomm drivers (maybe a future version of this image will, but at the moment Windows 11 23H2 ARM64 does not). To USB boot this we have to inject the Qualcomm drivers into boot.wim, once that is done I can USB boot with no issues on the Dell Inspiron 3420.
Unfortunately I don't recall which boot.wim above I was testing with back in my May comments...
I don't have my Dell Inspiron 3420 with me today but I will see if I can set aside some time in the coming weeks to get my setup going again and try the various boot.wim files to see what may work.
I appreciate everyone's effort here. If we can get wimboot working on the Dell Inspiron 3420 it can help streamline our imaging process.
Which drivers does it lack to boot? Win PE runs from memory, so it shouldn't need any driver at all to boot, having access to network and disk is a different matter.
When booting from USB .wim is loaded by bootmgr using the firmware drivers for USB/disk access. I'm not looking for a "working install" here, just getting in to WinPE, probably with some kind of error, instead of the reboot you are currently seeing.
I would not want to have any driver at all included in boot.wim, NIC drivers is injected by wimboot, and then loaded by script. Disk drivers is loaded by the windows installation using unattended.xml, this way only minimal drivers is loaded and crash bugs is avoided, but if they do crash, there will be clear pointers as to which driver is causing the crash.
Parts of this kind of logic (but not yet all) can be found in https://github.com/NiKiZe/wimboot-install
The Windows 11 23H2 ARM64 ISO provided by Microsoft VLC lacks storage, keyboard, and trackpad drivers (others as well) for the Dell Inspiron 3420. But yes sorry, I can USB boot that ISO but the install fails because of the missing drivers.
I've tried again using the release version of wimboot.arm64 and the unmodified Windows 11 23H2 ARM64 ISO provided by Microsoft VLC boot.wim but I'm still not having any luck. Same issues as before described on May 9th comment above, I see Loading files... and then it reboots.
May I ask what version of Windows 11 ARM64 are you using and where you obtained the ISO from?
In the coming months I'll hopefully be trialing Windows 11 ARM64 and Parallels Desktop on Macs. I'll let you know how things go.