after updating to a newer release of ipxe, started seing issue with wimboot. Specifically
http://ipxe.org/err/2e0080
Have latest (2.4.1) wimboot.
Works OK in a VM (hyper-v), but not on hardware machines (asus z97, and x99 boards).
Any ideas?
In most cases you get this when trying to boot an incompatible image from efi.
What kind of ipxe image have you booted and how, and where does your wimboot come from?
(2015-04-06 16:22)andlommy Wrote: [ -> ]ipxe built from https://git.ipxe.org/ipxe.git/commit/8c4...235b17eb58
are you using ipxe.efi snponly.efi, undionly.kpxe or what file are you actually using and how do you start it?
you could try an bitsect to find the first commit with the issue (or more correctly, the last commit that works)
(2015-04-06 16:25)NiKiZe Wrote: [ -> ] (2015-04-06 16:22)andlommy Wrote: [ -> ]ipxe built from https://git.ipxe.org/ipxe.git/commit/8c4...235b17eb58
are you using ipxe.efi snponly.efi, undionly.kpxe or what file are you actually using and how do you start it?
you could try an bitsect to find the first commit with the issue (or more correctly, the last commit that works)
ipxe.efi
snp.efi doesn't work right (probably needs another thread). For most boards it loads a nii driver, and shows up a device with MAC of 01:01:01:01:01:01 rather than proper (rtl8168 or whatever driver)
Update:
Sorted, was "Secure Boot" turned on. Interestingly enough it loaded memtest.efi, loaded ipxe boot menu, but not the wimboot...
Intersting, What kind of hardware was this on?
memtest.efi (from Microsoft I assume) is correctly signed to work with secure boot, while ipxe.efi and wimboot is not (yet) signed.
So it would be intersting to know if it is common for
efi -> ipxe -> memtest.efi to work
but not
efi -> ipxe -> wimboot -> bootmgr.efi
Thinking it might be possible to have non signed ipxe solution working with secure boot enabled.
about your snp not working it's most likely becuse both snp and nii is supported on the machine, which unfortunatly results in no device working (But sounds weird if a 01:01:01:01:01:01 device is found)
ipxe.efi is the most compatible solution for efi since it support most native devices and also nii and snp as falbacks. (but not if no native drivers is supported and have both nii and snp)
(2015-04-07 00:13)NiKiZe Wrote: [ -> ]Intersting, What kind of hardware was this on?
memtest.efi (from Microsoft I assume) is correctly signed to work with secure boot, while ipxe.efi and wimboot is not (yet) signed.
So it would be intersting to know if it is common for
efi -> ipxe -> memtest.efi to work
but not
efi -> ipxe -> wimboot -> bootmgr.efi
Thinking it might be possible to have non signed ipxe solution working with secure boot enabled.
about your snp not working it's most likely becuse both snp and nii is supported on the machine, which unfortunatly results in no device working (But sounds weird if a 01:01:01:01:01:01 device is found)
ipxe.efi is the most compatible solution for efi since it support most native devices and also nii and snp as falbacks. (but not if no native drivers is supported and have both nii and snp)
Asus X97 and Asus X99 (
http://www.asus.com/ie/Motherboards/RAMPAGE_V_EXTREME/) boards, as well as gigabyte boards (don't remember make)
memtest was from passmark (original memtest86 6.0 personal)
efi->ipxe->memtest worked indeed, however efi->ipxe->wimboot didn't, correct
Also one of the boards misbehaved while loading ipxe part, other loaded ipxe, but did't load memtest.
My goal for today was restoring production environment, so didn't test extensively.
Can continue complaining and mention a motherboard getting stuck on ipxe "initializing devices". Huge variety of hardware here, so plenty of various issues
![Confused Confused](https://forum.ipxe.org/images/smilies/confused.gif)