wimboot: no bootmgr.exe

[VirtualNobody]

I'm trying to use wimboot 3.0.1 and pxelinux.0 6.0.3-pre6 to boot SCCM.

I'm getting:
wimboot 1.0.3....

Emulating drive 0x81
Fatal: no bootmgr.exe

This is my menu file:
LABEL Windows SCCM installer NEW
com32 linux.c32
KERNEL wimboot
INITRDFILE windows/bootmgr.exe bootmgr.exe
INITRDFILE windows/bcd bcd
INITRDFILE windows/boot boot
INITRDFILE windows/boot.sdi boot.sdi
INITRDFILE windows/boot.wim boot.wim

If I use initrd instead of initrdfile I get a cpio error, and from googling, initrdfile is what is needed.

bootmgr.exe is from the 8.1 ADK.

A network trace shows no attempt by the client to even attempt to load bootmgr.exe from the server.

I would use ipxe chainload, but that's not currently working for me at the moment (see my other thread on that...)

Any ideas?

Thanks...

---

I have also tried this, with the same results...again, network trace shows no signs of attempting to load bootmgr.exe

LABEL Windows SCCM installer old
com32 linux.c32 wimboot
INITRDFILE windows/bootmgr.exe@bootmgr.exe,windows/bcd@bcd,windows/boot.sdi@boot.sdi,windows/boot.wim@boot.wim
APPEND wimboot

I have tried with and w/o the @program.

If I use initrd instead of initrdfile, it does load the files, then gives the cpio error.

[mcb30]

(2014-03-06 00:13)VirtualNobody Wrote:  This is my menu file:
LABEL Windows SCCM installer NEW
com32 linux.c32
KERNEL wimboot
INITRDFILE windows/bootmgr.exe bootmgr.exe
INITRDFILE windows/bcd bcd
INITRDFILE windows/boot boot
INITRDFILE windows/boot.sdi boot.sdi
INITRDFILE windows/boot.wim boot.wim

If I use initrd instead of initrdfile I get a cpio error, and from googling, initrdfile is what is needed.

bootmgr.exe is from the 8.1 ADK.

A network trace shows no attempt by the client to even attempt to load bootmgr.exe from the server.

Your configuration is asking pxelinux to load the bootmgr.exe file from the network; whatever is going wrong at that stage is not an iPXE or a wimboot problem.

I would suggest that you try loading iPXE directly (bypassing pxelinux), to simplify your setup and help narrow down which part is causing the problem. You can find instructions on using wimboot with iPXE at http://ipxe.org/wimboot and http://ipxe.org/howto/winpe.

Michael

[VirtualNobody]

I am looking at replacing lpxelinux with iPXE. One of the problems I'm trying to resolve is the recursive booting issue.

We are using Infoblox and Solaris DHCP servers. The documentation for resolving the recursive issue for user-options only discusses ISC and MS DHCP servers.

I'm not sure if the Solaris DHCP server is capable of doing the "if" constructs of the ISC DHCP server...And no, migrating is not an option at this time.

Is there another way around it? This will be used in a multi regional organization with regional DHCP and distribution web servers, so compiling in a specific script is also not really an option, as then someone would have to maintain a specific iPXE build for every region.

I was going to resolve this problem with lpxelinux using DHCP option 210, so after lpxelinux loads, it would reference the supplied HTTP server from option 210 as to where to go next. Does iPXE make use of DHCP option 210? I can't find any reference to it anywhere.

[VirtualNobody]

I'm not having much luck booting iPXE directly either.

Seems iPXE can't reach the default route for some reason. See attached. Also, ping and ipstat are listed as iPXE commands, yet it doesn't recognize them when I try to use them?

Other devices are able to access the default route just fine...

I'm trying to upload screen shots, but I keep getting: The file upload failed. Please choose a valid file and try again. Error details: There was a problem moving the uploaded file to its destinat

---

[VirtualNobody]

So it looks like I need to do an ifopen net0....(why is it closed?) to enable the interface.

It also looks like undionly.kpxe is not paying any attention to DHCP options 209 and 210.

If I manually chain boot the menu file, I can now get wimboot to load SCCM, but then I get the box:
Unable to read task sequence configuration disk.

Is there a pxe driver I need to have the Windows guys integrate with their config?

Or is this because the Windows group hasn't fully followed the SCCM how to? I had them take a look at the web page, and they said they would have to dig further as the how to was referencing out of date imagex instead of the new dism command, and they would need to investigate what else needs to change.

[mcb30]

(2014-03-07 00:20)VirtualNobody Wrote:  So it looks like I need to do an ifopen net0....(why is it closed?) to enable the interface.

Difficult to say why it's closed at that point without being able to see what happened immediately beforehand. The interface gets closed automatically after a failed DHCP attempt; could that be it? If you're manually setting a static IP address instead of using DHCP then you need the "ifopen" to open the interface, since nothing else will do it.

Quote:It also looks like undionly.kpxe is not paying any attention to DHCP options 209 and 210.

Correct; those are pxelinux extensions with no meaning to iPXE.

Quote:If I manually chain boot the menu file, I can now get wimboot to load SCCM, but then I get the box:
Unable to read task sequence configuration disk.

Is there a pxe driver I need to have the Windows guys integrate with their config?

Or is this because the Windows group hasn't fully followed the SCCM how to? I had them take a look at the web page, and they said they would have to dig further as the how to was referencing out of date imagex instead of the new dism command, and they would need to investigate what else needs to change.

If your Windows group hasn't modified the SCCM image as per the instructions on http://ipxe.org/howto/sccm, then you will get that error. The instructions for modifying SCCM are not purely decorative; they are required to make SCCM work when loaded via wimboot. (Parts of SCCM make some assumptions which are not valid when wimboot is used; e.g. that the virtual FAT filesystem created by wimboot remains accessible once Windows has started.)

Michael

[VirtualNobody]

(2014-03-07 16:45)mcb30 Wrote:  

(2014-03-07 00:20)VirtualNobody Wrote:  So it looks like I need to do an ifopen net0....(why is it closed?) to enable the interface.

Difficult to say why it's closed at that point without being able to see what happened immediately beforehand. The interface gets closed automatically after a failed DHCP attempt; could that be it? If you're manually setting a static IP address instead of using DHCP then you need the "ifopen" to open the interface, since nothing else will do it.

It doesn't seem to have failed, as ifstat shows there is an IP configured. an ifopen and then things start working.

Quote:It also looks like undionly.kpxe is not paying any attention to DHCP options 209 and 210.

Correct; those are pxelinux extensions with no meaning to iPXE.
[/quote]

Any chance of implementing 209 and 210? Seems like a more logical way of breaking the boot loop than compiling in a script or using and if/else construct in the DHCP server.

Quote:If I manually chain boot the menu file, I can now get wimboot to load SCCM, but then I get the box:
Unable to read task sequence configuration disk.

Is there a pxe driver I need to have the Windows guys integrate with their config?

Or is this because the Windows group hasn't fully followed the SCCM how to? I had them take a look at the web page, and they said they would have to dig further as the how to was referencing out of date imagex instead of the new dism command, and they would need to investigate what else needs to change.

If your Windows group hasn't modified the SCCM image as per the instructions on http://ipxe.org/howto/sccm, then you will get that error. The instructions for modifying SCCM are not purely decorative; they are required to make SCCM work when loaded via wimboot. (Parts of SCCM make some assumptions which are not valid when wimboot is used; e.g. that the virtual FAT filesystem created by wimboot remains accessible once Windows has started.)

[/quote]

OK, thanks...I haven't been able to get the Windows team to make those modifications yet, I guess I'll have to try and make them myself. I just needed to know if something else was still broken, or if this is hopefully my last step.

[VirtualNobody]

I made the bootstrap.vbs and winpeshl.ini modifications. Now when I boot, I get a CMD box stating it's configuring the DNS client, so it appears the bootstrap.vbs file is triggering, then *poof* it reboots.

Any idea what I did wrong? Is the bootstrap.vbs and winpeshl.ini available as a download anywhere? I would feel more comfortable with that then cutting and pasting from a web page, and possibly getting errors that way.

I didn't see them in the ipxe source tree or in git.ipxe.org.

[mcb30]

(2014-03-11 21:19)VirtualNobody Wrote:  I made the bootstrap.vbs and winpeshl.ini modifications. Now when I boot, I get a CMD box stating it's configuring the DNS client, so it appears the bootstrap.vbs file is triggering, then *poof* it reboots.

Any idea what I did wrong? Is the bootstrap.vbs and winpeshl.ini available as a download anywhere? I would feel more comfortable with that then cutting and pasting from a web page, and possibly getting errors that way.

No; they exist only as part of the documentation.

You could try modifying bootstrap.vbs so that it contains only the first two lines:

Code:

Set os = WScript.CreateObject ( "WScript.Shell" )
os.Run "%COMSPEC%", 7, false

That should get you a (minimized) command window which you can open and experiment with.

Michael

[VirtualNobody]

(2014-03-12 15:57)mcb30 Wrote:  That should get you a (minimized) command window which you can open and experiment with.

Good idea...I'm getting the same issue though...I get the boot screen with the spinning dots, then I get our background, then *poof* again, reboot...Happens so fast I didn't even see the minimized window get created.

So it appears that as soon as the bootstrap.vbs script is done executing, it reboots.

[mcb30]

(2014-03-12 17:49)VirtualNobody Wrote:  Good idea...I'm getting the same issue though...I get the boot screen with the spinning dots, then I get our background, then *poof* again, reboot...Happens so fast I didn't even see the minimized window get created.

So it appears that as soon as the bootstrap.vbs script is done executing, it reboots.

Should be easy to test that theory:

Code:

Set os = WScript.CreateObject ( "WScript.Shell" )
os.Run "%COMSPEC%", 7, false
WScript.MsgBox ( "Click me to exit script" )

(I haven't tested this code, and don't know if that syntax is correct, but hopefully the concept is clear.)

Michael

[VirtualNobody]

So on that theory I went back to our original winpeshl.ini file to see what was in it. I then put the bootstrap.ini execution before that, so now it looks like:

[LaunchApps]
"wscript.exe","%SYSTEMDRIVE%\sms\bin\x64\bootstrap.vbs"
%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

So now it's going past the reboot, and I'm getting stuck where I was before...Unable to read task sequence configuration disk.

I also have the cmd.exe window I can play in...IP configuration seems to be correct, I can ping the HTTP server on another network. I have an X drive that has the boot.wim image mounted...

What the heck is this thing still looking for?

Thanks for getting me this far...

[mcb30]

(2014-03-12 18:06)VirtualNobody Wrote:  [LaunchApps]
"wscript.exe","%SYSTEMDRIVE%\sms\bin\x64\bootstrap.vbs"
%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

So now it's going past the reboot, and I'm getting stuck where I was before...Unable to read task sequence configuration disk.

Yes, that's expected. The whole point of the custom bootstrap.vbs is to bypass TsBootShell.exe (which does not work correctly when started via wimboot) and directly set up the environment needed to run TsmBootStrap.exe.

Quote:I also have the cmd.exe window I can play in...IP configuration seems to be correct, I can ping the HTTP server on another network. I have an X drive that has the boot.wim image mounted...

What the heck is this thing still looking for?

From within the command window, are you able to run:

Code:

wpeinit
net start dnscache

without problems?

Michael

[VirtualNobody]

So, reading comprehension is key...

I missed the step to copy the sms/bin directory into the boot.wim image. I just glossed over it since I was using someone else's SCCM ISO, so my mind just concluded that step had been done already. Ouch.

Now that I did that, it seems to be working fine.

Thanks for all the help!

Is there any chance of getting DHCP options 209 and 210 implemented? Seems like a more straightforward approach to break the boot loop.

[mcb30]

(2014-03-17 21:54)VirtualNobody Wrote:  Is there any chance of getting DHCP options 209 and 210 implemented? Seems like a more straightforward approach to break the boot loop.

Considering it. RFC5071 seems to suggest that we could treat option 209 as the URL of an iPXE script to use, as a preferred alternative to the usual DHCP filename.

Coding this would be fairly straightforward. The tricky part is trying not to break any conceivable existing setup (including sites which use both iPXE and pxelinux).

Michael

[VirtualNobody]

(2014-03-19 13:50)mcb30 Wrote:  Considering it. RFC5071 seems to suggest that we could treat option 209 as the URL of an iPXE script to use, as a preferred alternative to the usual DHCP filename.

Coding this would be fairly straightforward. The tricky part is trying not to break any conceivable existing setup (including sites which use both iPXE and pxelinux).

Michael

I believe 209 holds the path to the config file ( /ipxe-boot/boot.ipxe) and 210 holds the server ( http://server/ ).

If memory serves, I believe the RFC said 208 is no longer in use by pxelinux...But I suppose it would be bad to just assume ownership of it....

You could just make the option number a compile time setting, then people could just use one of the site-options as desired...Put the entire path to the script in one option.

[VirtualNobody]

Hi...

Anymore thought on implementing DHCP options 209 and 210?

We are trying to roll out iPXE with Infoblox as our IP management solution and it's not making the if/then logic construct easy. It can only be done at the global level (our support staff wont do that) or at the scope level.

Unfortunetly, in IB lingo, scope means anytime there's a fixed address in a class C, you have to create another scope around it. So this could mean implenting the logic for a single class C subnet many times.

This is making our rollout of iPXE hard.

Thanks.

[robinsmidsrod]

Multimediaman (here on the forum) has posted earlier about how he solved an environment iPXE and a LOT of DHCP servers and different regions. I can't find the post in question right now, but if you scan through his posts you should probably find it. It might give you some ideas on how to solve your challenge.