[mchipser]

I just switched from using WDS to deploy my images to using tftp-hpa / pxelinux. This works wonderfully except one small time issue. When pointing pxelinux to the pxeboot.0 it takes approximately 30 seconds for bootmgr to find the BCD and launch the wim. I only found one article about this here. Is it possible to load bootmgr directly and not use pxeboot.0?

I have tried the following with no luck

LABEL test1
COM32 chain.c32
APPEND boot ntldr=/BOOTMGR

LABEL test2
COM32 chain.c32
APPEND fs ntldr=/BOOTMGR

This however works, but with the delay

LABEL Deployments with pass
COM32 chain.c32
kernel Boot/pxeboot.0

This post has been edited by mchipser: 11 September 2012 - 03:40 PM

[jaclaz]

It would be interesting to understand if it's linked exclusively to the pxelinux way of loading BOOTMGR (whatever this way is) or if it is "generic".
But the fix suggested in the given link seems to me "logical", why cannot you use it?

Maybe you could try using grub4dos instead of pxelinux and see if the delay is the same:
https://sites.google...w/tutorials/pxe
http://diddy.boot-land.net/pxe/

And/or you could try the "new kid on the block", Serva:
http://www.vercot.co...va/default.html
https://sites.google...tutorials/serva
which does have a "WAIK independent" WDS server.

jaclaz

[mchipser]

I would expect similar behavior between the syslinux projects (iso, pxe, sys)

This works fine under isolinux, but not pxelinux. It says file can not be found.

LABEL test2
COM32 chain.c32
APPEND ntldr=/BOOTMGR

I am gonna try grub4dos and see if it removes the wait.

This post has been edited by mchipser: 12 September 2012 - 08:26 AM

[Tripredacus]

I don't have much of a delay... maybe less than 2 seconds. Except mine just says

LABEL wds
MENU DEFAULT
MENU LABEL Windows Deployment Services
KERNEL pxeboot.0

[mchipser]

Here is my current file (I had to move pxeboot.0 to the root of the tftp directory though)

LABEL Deployments
COM32 chain.c32
kernel pxeboot.0

https://www.youtube....ayer_detailpage is a video of the boot time.

This post has been edited by mchipser: 12 September 2012 - 09:31 AM

[mchipser]

I think i might have found the issue.. still not sure how to fix it though..

pxeboot.0 boots bootmgr.exe not bootmgr, the file sizes are different though, bootmgr is 375KB bootmgr.exe is 512KB.. when trying to boot bootmgr.exe straight from pxelinux i get an error saying the file is to large..

when booting bootmgr i get a bootmgr error.. Unable to load BCD. 0xc0000225

This post has been edited by mchipser: 12 September 2012 - 10:15 AM

[kyor]

I had the same issue several years ago with Windows 7. So i still use the Vista files to boot my Winpe4 Image without any delay.

[mchipser]

kyor, on 12 September 2012 - 10:17 AM, said:

I had the same issue several years ago with Windows 7. So i still use the Vista files to boot my Winpe4 Image without any delay.

same issue? The boot time or the 0xc0000225 error?

I just tried a bootmgr from server 2008, should be the same as vista with no luck.

This post has been edited by mchipser: 12 September 2012 - 10:40 AM

[kyor]

I had a delay when i tried to load Winpe from PXE. I don't get a a error message

[mchipser]

Maybe i need the bootmgr.exe from vista.. not the bootmgr

Edit: I tried the vista bootmgr.exe with the same results..

This post has been edited by mchipser: 12 September 2012 - 09:11 PM

[mchipser]

I think the problem lies in how bootmgr.exe looks for the BCD, which is confirmed from the post earlier; however why cant i use bootmgr from pxelinux? I think it is an issue with using a *nix tftp server. I thought this would be fixed by using the remap feature of the tftp server, but apparently not..

when booting from isolinux i can boot bootmgr fine with no delay.

When trying to boot bootmgr from pxelinux it can not find the bcd but booting bootmgr.exe it find it with the delay..

I am going to try using a windows based tftp server and see what happens

EDIT:

here is a copy of my remap file.

re ^BCD Boot/BCD
r ^\\Boot\\ Boot/
r ^\\boot\\ Boot/
rg \\ /1

This post has been edited by mchipser: 13 September 2012 - 09:57 AM

[mchipser]

well i have been trying to get grub to boot the bootmgr / bootmgr.exe with no luck.. this is using TFTPD32

I keep getting an error..

Error 13: Invalid or unsupported executable format

The menu.lst looks like:

title winpe
pxe keep
chainloader /bootmgr

with this menu.lst i get this error

title winpe
pxe keep
chainloader --raw(pd)/bootmgr

Error 1: Filename must be either an absolute pathname or blocklist

This post has been edited by mchipser: 13 September 2012 - 03:43 PM

[mchipser]

I ended up doing what I found in the first post.. It doesn't completely remove the wait but reduces it quite a bit.. Until i find something better..

I tired to add the option 252 to my dhcp server but that didn't fix the issue.

Still not sure why syslinux & ioslinux perform different than pxelinux..

This post has been edited by mchipser: 14 September 2012 - 09:14 AM

[jaclaz]

mchipser, on 13 September 2012 - 09:49 AM, said:

I think the problem lies in how bootmgr.exe looks for the BCD, which is confirmed from the post earlier; however why cant i use bootmgr from pxelinux? I think it is an issue with using a *nix tftp server. I thought this would be fixed by using the remap feature of the tftp server, but apparently not..

when booting from isolinux i can boot bootmgr fine with no delay.

When trying to boot bootmgr from pxelinux it can not find the bcd but booting bootmgr.exe it find it with the delay..

BOOTMGR and BOOTMGR.EXE are actually the "same" file BUT the second has some added code to make it a suitable "pxe" target. EDIT: BUT the first has some added code (16 bit) to make it a "local boot" target.

EXACTLY like it was in the good ol'days with SETUPLDR and SETUPLDR.EXE, see:
http://reboot.pro/5900/
http://reboot.pro/4952/#entry40701

It seems to me like you pinned down exactly the problem, i.e. the way BOOTGR.EXE looks for the BCD, and right now it seems to me like there are only the metioned ways out:

• use an original WDS server
  
• using the workaround you found http://www.0xf8.org/...m-via-pxelinux/
  
• using an alternate WDS server (suggested but UNtested)
  
• using an alternate loader from pxelinux (suggested but UNtested)

Another possibility (also to be tested) is here:
http://reboot.pro/1656/
http://www.ultimated...7pxelinux1.html


jaclaz

This post has been edited by jaclaz: 14 September 2012 - 11:58 AM

[kyor]

@mchipser

if you like you can test my bootmgr.exe that i use for years with Linux without delay

For testing purpose i have uploaded it to
http://exfile.ru/372587

Greetings
kyor

[joakim]

jaclaz, on 14 September 2012 - 10:28 AM, said:

BOOTMGR and BOOTMGR.EXE are actually the "same" file BUT the second has some added code to make it a suitable "pxe" target.

Being a little picky, but it would be more correct to say something like;

"BOOTMGR and BOOTMGR.EXE are actually the same file, but the first has some added code (16-bit) to make it a suitable local boot target"

[jaclaz]

joakim, on 14 September 2012 - 11:42 AM, said:

jaclaz, on 14 September 2012 - 10:28 AM, said:

BOOTMGR and BOOTMGR.EXE are actually the "same" file BUT the second has some added code to make it a suitable "pxe" target.

Being a little picky, but it would be more correct to say something like;

"BOOTMGR and BOOTMGR.EXE are actually the same file, but the first has some added code (16-bit) to make it a suitable local boot target"

Yep , my bad I got it the "other way round" .

jaclaz

[mchipser]

joakim, on 14 September 2012 - 11:42 AM, said:

jaclaz, on 14 September 2012 - 10:28 AM, said:

BOOTMGR and BOOTMGR.EXE are actually the "same" file BUT the second has some added code to make it a suitable "pxe" target.

Being a little picky, but it would be more correct to say something like;

"BOOTMGR and BOOTMGR.EXE are actually the same file, but the first has some added code (16-bit) to make it a suitable local boot target"

I think the .exe version has the extra code, at least it is a bigger sized file..

[mchipser]

jaclaz, on 14 September 2012 - 10:28 AM, said:

mchipser, on 13 September 2012 - 09:49 AM, said:

I think the problem lies in how bootmgr.exe looks for the BCD, which is confirmed from the post earlier; however why cant i use bootmgr from pxelinux? I think it is an issue with using a *nix tftp server. I thought this would be fixed by using the remap feature of the tftp server, but apparently not..

when booting from isolinux i can boot bootmgr fine with no delay.

When trying to boot bootmgr from pxelinux it can not find the bcd but booting bootmgr.exe it find it with the delay..

BOOTMGR and BOOTMGR.EXE are actually the "same" file BUT the second has some added code to make it a suitable "pxe" target. EDIT: BUT the first has some added code (16 bit) to make it a "local boot" target.

EXACTLY like it was in the good ol'days with SETUPLDR and SETUPLDR.EXE, see:
http://reboot.pro/5900/
http://reboot.pro/4952/#entry40701

It seems to me like you pinned down exactly the problem, i.e. the way BOOTGR.EXE looks for the BCD, and right now it seems to me like there are only the metioned ways out:

• use an original WDS server
  
• using the workaround you found http://www.0xf8.org/...m-via-pxelinux/
  
• using an alternate WDS server (suggested but UNtested)
  
• using an alternate loader from pxelinux (suggested but UNtested)

Another possibility (also to be tested) is here:
http://reboot.pro/1656/
http://www.ultimated...7pxelinux1.html


jaclaz

• use an original WDS server
  
• using the workaround you found http://www.0xf8.org/...m-via-pxelinux/
  
• using an alternate WDS server (suggested but UNtested)
  
• using an alternate loader from pxelinux (suggested but UNtested)

I am currently using #2.. What other loaders can i use from pxelinux besides grub4dos / grldr, since that one kept giving me errors.

This post has been edited by mchipser: 14 September 2012 - 12:19 PM

[joakim]

mchipser, on 14 September 2012 - 12:16 PM, said:

I think the .exe version has the extra code, at least it is a bigger sized file..

Trust me, bootmgr has every single byte of bootmgr.exe, plus some more (16-bit). It's just that bootgmr.exe is compressed when residing "inside" bootmgr.