wimboot Custom boot.wim

[yvkr]

Hi,

booting the original boot.wim (around 140MB) from my Win7 x86 DVD using iPXE and wimboot works fine.

I created a custom boot.wim (around 180MB) using Winbuilder (Project Win7PESE) which works fine too.

Adding some Tools to the Build makes the boot.wim around 421MB.
Booting this with wimboot results in an Error 0xc0000017 (see attached Screenshot).

Booting the big ISO file using memdisk works fine.

The Test run in a VMware with 4GB of RAM.

This is the iPXE Script:

Code:

#!ipxe

#initrd http://10.0.1.7/avpe/pe.iso
#chain http://10.0.1.7/avpe/memdisk iso raw
#boot


kernel http://10.0.1.7/avpe/wimboot
initrd http://10.0.1.7/avpe/bootmgr     bootmgr
initrd http://10.0.1.7/avpe/bcd         BCD
initrd http://10.0.1.7/avpe/boot.sdi    boot.sdi
initrd http://10.0.1.7/avpe/boot.wim    boot.wim
boot

Is this a "Bug" related to wimboot and the boot.wim size or did I miss something?

Thanks for any help!

[robinsmidsrod]

0xC0000017 does mean STATUS_NO_MEMORY ({Not Enough Quota} Not enough virtual memory or paging file quota is available to complete the specified operation.) according to the Windows Error Lookup Tool, so it is possible you don't have enough of some kind of memory, or you're hitting some kind of memory type limit.

I'd try to take one of the boot.wim files that works okay, and add an additional dummy file into it to make it about the same size as the one that fails. If you get the same error then it does seem to be a wimboot bug that should be reported to the mailing-list.

[Sha0]

Are you able to reproduce the error by omitting the raw parameter to MEMDISK or trying other combinations of memory parameters for MEMDISK? Also, can I assume that your pe.iso has the very same .WIM inside it?

[yvkr]

Hi,

it seems the Problem is just about the size of boot.wim not the content.
I took a working boot.wim with a size of about 267MB and began adding dummy data just by using dd
(dd if=/dev/urandom bs=1M count=5 >> boot.wim).

It still worked at a size of 322MB.
It stopped working at a size of 330MB.
At 330MB, the errror message changed to the one attached.    
(File: NETIO.SYS, Status 0xc0000017)
Adding another 5MB changed the error message back to the original one. (Only Status: 0xc0000017 without giving a file)


The ISO File contains the very same first big boot.wim and has a total size of about 438MB.
Omitting the raw Parameter to MEMDISK makes the VMware showing only a black screen after loading the iso and beginning to boot.

[Nostradamus]

Hi,

I am facing exactly the same problem as yvkr.
WIM files below a size of 330MB boot fine using wimboot V1.0.3 from a fresh compile of today's git clone (same with included wimboot in the ZIP). Larger WIM files result in the 0xc0000017 status.
All files boot fine using wdsnbp chainloaded via pxelinux.
I chainload ipxe.pxe renamed to ipxe.0 via pxelinux for testing - and fail...

pxelinux cfg (snippet):

Code:

LABEL ipxe
  MENU LABEL ^iPXE SAN Boot
    KERNEL ipxe/ipxe.0

boot.ipxe assigned via dhcpd.conf (snippet)

Code:

    if exists user-class {
        if option user-class = "iPXE" {
            filename "http://xxx.xxx.xxx.xxx/boot.ipxe";
            }
            else if option user-class = "gPXE" {
            filename "http://xxx.xxx.xxx.xxx/boot.gpxe";
            }
    }

boot.ipxe (snippet):

Code:

#!ipxe

kernel wimboot/wimboot
initrd wimboot/bootmgr                       bootmgr
initrd wimboot/boot/bcd                      BCD
initrd wimboot/boot/fonts/segmono_boot.ttf   segmono_boot.ttf
initrd wimboot/boot/fonts/segoe_slboot.ttf   segoe_slboot.ttf
initrd wimboot/boot/fonts/wgl4_boot.ttf      wgl4_boot.ttf
initrd wimboot/boot/boot.sdi                 boot.sdi
initrd wimboot/sources/boot.wim              boot.wim
boot wimboot

Did anybody find a solution yet?

Best regards

[ssd]

I've also had problems getting ipxe to load large images.
I looked at the wimboot source, and it is expecting the files in a cpio archive. A little experimentation with options to get the format right, and I found this to work:

echo bootmgr BCD boot.sdi boot.wim | fmt -1 | cpio -H newc -v -o > ../wimfiles.cpio

Then I used ipxe to boot syslinux, and syslinux to load wimboot as kernel and wimfiles.cpio as initrd

This loads quite fine...not as convenient as using ipxe directly, but it works. So at least i know it's not wimboot getting it wrong.

Maybe syslinux is getting the memory map more correct or something.
However, even with this method, some machines (with limited memory) don't work, where the same files loaded as a bootable iso instead of a wim with wimboot works, so it probably needs double the memory or something.

[robinsmidsrod]

ssd: This is interesting. I think this might mean that iPXE is having issues when it is trying to load a file and turn it into a cpio archive _on the fly_, but only if the downloaded file is 330MB or larger.

This should be reported to the developer mailing-list.

If you have the opportunity to test, does it also work if you do something like this in an ipxe script?

Code:

#!ipxe
kernel wimboot
initrd wimfiles.cpio
boot

If it does, that seems to indicate it's the cpio-archive-on-the-fly generation which the initrd ipxe command does has an issue with large files (>330MB).

[ssd]

(2013-10-05 14:41)robinsmidsrod Wrote:  If it does, that seems to indicate it's the cpio-archive-on-the-fly generation which the initrd ipxe command does has an issue with large files (>330MB).

Tested using the same cpio output file I am using with syslinux, and ipxe loads it fine, so your cpio on the fly construction must be buggy.

Additionally, this method loaded the image *extremely* fast.
I suspect there is a problem between ipxe/syslinux reducing throughput when syslinux loads files.

Hmmm...on further testing, both methods work on this machine, it only fails on some machines, so it could still be a memory issue.

[robinsmidsrod]

ssd: Thanks for the testing. Hopefully some of the core developers can figure out what the exact issue is now.

[ssd]

Ok, I've got a new wim image that won't boot on at least one machine.
ipxe won't boot it either as a separate file or in the cpio -- it hands windows a corrupted image.

syslinux loads it fine. So it's ipxe itself, not the cpio construction.

[robinsmidsrod]

I saw a post on the mailing-list about this issue the other day. It is a more technical audience in general. I'd suggest you follow up there.