Jump to content











Photo
- - - - -

Booting WinPE via HTTP

http winpe ipxe wimboot ramdisk

  • Please log in to reply
66 replies to this topic

#51 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 27 March 2013 - 02:31 PM

#!ipxe
kernel http://10.57.1.62:80/wimboot
initrd http://10.57.1.62:80/bootmgr
initrd http://10.57.1.62:80/Boot/bcd
initrd http://10.57.1.62:80/Boot/boot.sdi
initrd http://10.57.1.62:8080/WinPE2.wim
boot
 
Maybe you can give me a hint how I can solve the problem?

As per the documentation at http://ipxe.org/wimboot, you need to provide filenames for each file that you want to appear within the initrd as passed to wimboot. Try changing your script to:
 
#!ipxe
kernel http://10.57.1.62:80/wimboot
initrd http://10.57.1.62:80/bootmgr         bootmgr
initrd http://10.57.1.62:80/Boot/bcd        BCD
initrd http://10.57.1.62:80/Boot/boot.sdi   boot.sdi
initrd http://10.57.1.62:8080/WinPE2.wim    boot.wim
boot

I've assumed that you're using a stock BCD file which expects a filename of "boot.wim" rather than "WinPE2.wim". If your BCD file really does expect a filename of "WinPE2.wim", then use:
 
 
#!ipxe
kernel http://10.57.1.62:80/wimboot
initrd http://10.57.1.62:80/bootmgr         bootmgr
initrd http://10.57.1.62:80/Boot/bcd        BCD
initrd http://10.57.1.62:80/Boot/boot.sdi   boot.sdi
initrd http://10.57.1.62:8080/WinPE2.wim    WinPE2.wim
boot

Michael

#52 glitch

glitch
  • Members
  • 3 posts
  •  
    Denmark

Posted 27 March 2013 - 05:25 PM

Thanks a lot!, it works like intended now and it all makes sense. I must have though it was unnessesary with defining the files what they are used for, since the files was downloading fine :)

 

What is the easiest way to automate the iPXE boot cd do both "dhcp net0" and "boot http://ip/file" ?

 

In the documentation at: http://ipxe.org/howto/sccmhttp://ipxe.org/howto/sccm

I have created "bootstrap.vbs" and "winpeshl.ini", then I was wondering when are they being used in the guide? am I supposed to run the vbs script anytime?

 

/Jesper



#53 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 27 March 2013 - 05:32 PM

What is the easiest way to automate the iPXE boot cd do both "dhcp net0" and "boot http://ip/file" ?

There's documentation on creating iPXE scripts at http://ipxe.org/scripting. You probably want something like an embedded script containing:
#!ipxe
dhcp
boot http://ip/file
In the documentation at: http://ipxe.org/howto/sccm
I have created "bootstrap.vbs" and "winpeshl.ini", then I was wondering when are they being used in the guide? am I supposed to run the vbs script anytime?

If you're not using SCCM then you can ignore the instructions on that page. If you are, then you will end up modifying the SCCM boot image to include those files as described here

Michael

#54 superapan

superapan
  • Members
  • 3 posts
  •  
    Sweden

Posted 28 March 2013 - 08:11 AM

Heya! I thought I had posted already a few hours ago, but something must've went wrong....

 

I'm trying to install and boot Win7 to an iSCSI target using iPXE and wimboot. The installer starts fine as long as I haven't attached the iSCSI target in iPXE. When I do, I get the bad CPIO magic-error. It's only after I've used the sanhook command and attached it. The script below is according to the documentation, with naming and everything - besides, it does work as long as I don't have the SAN attached.

 

What could be wrong? Any help is much appreciated <3.

 

  #!ipxe
  
  kernel wimboot
  initrd bootmgr          bootmgr
  initrd boot/bcd         BCD
  initrd boot/boot.sdi    boot.sdi
  initrd sources/boot.wim boot.wim
  boot


#55 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 28 March 2013 - 01:01 PM

I'm trying to install and boot Win7 to an iSCSI target using iPXE and wimboot. The installer starts fine as long as I haven't attached the iSCSI target in iPXE. When I do, I get the bad CPIO magic-error. It's only after I've used the sanhook command and attached it. The script below is according to the documentation, with naming and everything - besides, it does work as long as I don't have the SAN attached.
  #!ipxe
  
  kernel wimboot
  initrd bootmgr          bootmgr
  initrd boot/bcd         BCD
  initrd boot/boot.sdi    boot.sdi
  initrd sources/boot.wim boot.wim
  boot
 



That script will not attach any SAN target. Could you post the exact script that you are using which triggers the failure?

It may also be useful to add an "imgstat" command immediately before "boot": that will show if you have any other images unexpectedly loaded which may be interfering with the initrd construction.

Thanks,

Michael

#56 superapan

superapan
  • Members
  • 3 posts
  •  
    Sweden

Posted 28 March 2013 - 05:16 PM

That script will not attach any SAN target. Could you post the exact script that you are using which triggers the failure?

It may also be useful to add an "imgstat" command immediately before "boot": that will show if you have any other images unexpectedly loaded which may be interfering with the initrd construction.

Thanks,

Michael

 

Thank you for showing interest in my problem, Michael!

 

I start by running script lol.ipxe on my web server which also resides the iSCSI target.

 

 

chain http://192.168.1.100/win7/lol.ipxe

#!ipxe

dhcp net0
sanhook iscsi:192.168.1.100::::iqn.xxxxx.xxxx.xxx:xxxxxxxx.xxxx
set keep-san 1

after that I run

 

chain http://192.168.1.100/win7/boot.ipxe

 

#!ipxe
  
kernel wimboot
initrd bootmgr          bootmgr
initrd boot/bcd         BCD
initrd boot/boot.sdi    boot.sdi
initrd sources/boot.wim boot.wim
imgstat
boot

 

Which generates the error

 

bild.jpg

 

However, if I skip attaching the iSCSI-target (and thus eliminating the possibility of installing to it ;-)), the installation runs.

 

Weird, huh?



#57 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 28 March 2013 - 05:40 PM

Weird, huh?

The problem is that your "lol.ipxe" script is still present at the time you load wimboot, as can be seen from your screenshot:
lol.ipxe : 109 bytes [script]
wimboot : 11708 bytes [bzImage] [SELECTED]
bootmgr : 383786 bytes "bootmgr"
bcd : 262144 bytes "BCD"
boot.sdi : 3170304 bytes "boot.sdi"
boot.wim : 144734329 bytes "boot.wim"

This will cause iPXE to treat "lol.ipxe" as an initrd image, and pass it to wimboot. Since "lol.ipxe" isn't actually an initrd, you get the "Bad CPIO magic" error.

If you were to merge all the commands into a single script:
#!ipxe
dhcp
sanhook iscsi:192.168.1.100::::iqn.xxxxx.xxxx.xxx:xxxxxxxx.xxxx
kernel wimboot
initrd bootmgr bootmgr
initrd boot/bcd BCD
initrd boot/boot.sdi boot.sdi
initrd sources/boot.wim boot.wim
boot

then you should find that everything works.

Alternatively, you could free the "lol.ipxe" script before running "boot.ipxe":
chain http://192.168.1.100/win7/lol.ipxe
imgfree
chain http://192.168.1.100/win7/boot.ipxe

The same effect can also be achieved using the (not yet documented) "--autofree" / "-a" option when running "lol.ipxe":
chain -a http://192.168.1.100/win7/lol.ipxe
chain http://192.168.1.100/win7/boot.ipxe

HTH,

Michael

#58 superapan

superapan
  • Members
  • 3 posts
  •  
    Sweden

Posted 30 March 2013 - 11:51 AM

Ah, much thanks, apparently I didn't understand the concept of scripting.

 

Now the installation loads. But there seems to be something fishy with the iSCSI. If I have it attached, the installer just sits and loads endlessly until it times out (the Win8 spinning ball). It does work flawlessly without the iSCSI attached.

 

All this got me thinking (gasp). Is it even possible to attach an iSCSI target in iPXE, load the Win8 installer and expect to be able to install to it? I got it working without a sweat in Ubuntu, but is what I describe even a working feature with Windows?



#59 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 30 March 2013 - 02:26 PM

Now the installation loads. But there seems to be something fishy with the iSCSI. If I have it attached, the installer just sits and loads endlessly until it times out (the Win8 spinning ball). It does work flawlessly without the iSCSI attached.
 
All this got me thinking (gasp). Is it even possible to attach an iSCSI target in iPXE, load the Win8 installer and expect to be able to install to it? I got it working without a sweat in Ubuntu, but is what I describe even a working feature with Windows?

Yes, it should work. However, there's an irritating problem:

When Windows detects an iSCSI Boot Firmware Table (iBFT), and uses it to attach to an iSCSI target, it will wait for a long time (60-120 seconds) for the boot disk to appear. When you are using wimboot, the boot disk is a virtual disk which ceases to exist the moment that the Windows kernel starts up. Windows will therefore sit for a long time waiting for a boot disk that is never going to show up. Eventually it should time out and give up. On a normal system boot, you would see a STOP 0x0000007b if this happened. In this case, you already have everything loaded from boot.wim, so the system will be able to continue to run the installer.

I have not managed to find any sensible way around this annoying delay. I did consider changing wimboot to generate a virtual ISO rather than a virtual HDD; this might be able to fix the problem. (If anyone wants to fund this piece of work, please get in touch.)

In the meantime, be patient and you should eventually see Windows drop through and launch the installer.

Michael

#60 biatche

biatche

    Member

  • Members
  • 86 posts
  •  
    Malaysia

Posted 22 April 2013 - 08:19 PM

thanks for wimboot

 

 

echo Booting Windows PE
#cpuid --ext 29 && set arch amd64 || set arch x86
kernel ${boot-url}/wimboot
initrd ${boot-url}/bootmgr.exe bootmgr.exe
initrd ${boot-url}/boot/bcd BCD
initrd ${boot-url}/boot/Fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd ${boot-url}/boot/boot.sdi boot.sdi
initrd ${boot-url}/windows/win7pe_se.wim win7pe_se.wim
boot
goto start

 

 

ipxe end loads...... then..

 

 

Windows Boot Manager
0xc000000f
The boot selection failed because a required device is inaccessible.

 

 

ive tried setting to boot.wim also

 

It works fine in pxelinux via

 

"label 0
        menu label ^0) WinPE v3.1
        pxe /boot/pxeboot.n12"

 

I do have this below if this mean anything..

 

%BCDEDIT% /set %GUID1% osdevice ramdisk=[boot]\windows\win7pe_se.wim,{ramdiskoptions}

 

 

What have I done wrong?

 

should i try:

initrd ${boot-url}/windows/win7pe_se.wim windows\win7pe_se.wim

 

? maybe?

 

also

 

initrd ${boot-url}/bootmgr.exe bootmgr.exe

why are your examples without the .exe extension? it wouldnt boot here without bootmgr.--EXE--


Edited by biatche, 22 April 2013 - 08:26 PM.


#61 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 22 April 2013 - 09:12 PM

I do have this below if this mean anything..
 
%BCDEDIT% /set %GUID1% osdevice ramdisk=[boot]\windows\win7pe_se.wim,{ramdiskoptions}


The problem is that your BCD data instructs bootmgr to look in the \windows folder, and this folder doesn't exist within the virtual filesystem provided by wimboot. Change this to

%BCDEDIT% /set %GUID1% osdevice ramdisk=[boot]\sources\win7pe_se.wim,{ramdiskoptions}

and all should be well.

For reference, wimboot creates the following directory structure within the virtual disk:

\BOOT
\BOOT\FONTS
\BOOT\RESOURCES
\SOURCES

All files appear in all of the virtual directories.

initrd ${boot-url}/bootmgr.exe bootmgr.exe
why are your examples without the .exe extension? it wouldnt boot here without bootmgr.--EXE--


bootmgr.exe is not provided as a standalone file on the Windows installation media. bootmgr (without .exe) is provided on the Windows installation media, and contains a compressed copy of bootmgr.exe. wimboot contains code to automatically extract this embedded bootmgr.exe from bootmgr. This is done to make life easier for users; the alternative would be to provide a lengthy set of instructions on how to obtain or extract a copy of bootmgr.exe.

Michael


#62 biatche

biatche

    Member

  • Members
  • 86 posts
  •  
    Malaysia

Posted 22 April 2013 - 09:17 PM

I do have this below if this mean anything..
 
%BCDEDIT% /set %GUID1% osdevice ramdisk=[boot]\windows\win7pe_se.wim,{ramdiskoptions}


The problem is that your BCD data instructs bootmgr to look in the \windows folder, and this folder doesn't exist within the virtual filesystem provided by wimboot. Change this to

%BCDEDIT% /set %GUID1% osdevice ramdisk=[boot]\sources\win7pe_se.wim,{ramdiskoptions}
and all should be well.

For reference, wimboot creates the following directory structure within the virtual disk:

\BOOT
\BOOT\FONTS
\BOOT\RESOURCES
\SOURCES

All files appear in all of the virtual directories.

initrd ${boot-url}/bootmgr.exe bootmgr.exe
why are your examples without the .exe extension? it wouldnt boot here without bootmgr.--EXE--

bootmgr.exe is not provided as a standalone file on the Windows installation media. bootmgr (without .exe) is provided on the Windows installation media, and contains a compressed copy of bootmgr.exe. wimboot contains code to automatically extract this embedded bootmgr.exe from bootmgr. This is done to make life easier for users; the alternative would be to provide a lengthy set of instructions on how to obtain or extract a copy of bootmgr.exe.

Michael

 

Thanks ill give it a try later.

 

initrd ${boot-url}/bootmgr.exe bootmgr.exe <-- what should i do about this? use this as i always have (since pxelinux) or to obtain a compressed copy of bootmgr?



#63 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 22 April 2013 - 10:04 PM

initrd ${boot-url}/bootmgr.exe bootmgr.exe <-- what should i do about this? use this as i always have (since pxelinux) or to obtain a compressed copy of bootmgr?

Since you have a copy of bootmgr.exe available, then you may as well use it. The auto-extraction facility is intended only to make life easier for users who don't have an easy way to get hold of bootmgr.exe. It's totally fine to keep:
initrd ${boot-url}/bootmgr.exe bootmgr.exe

Michael

#64 biatche

biatche

    Member

  • Members
  • 86 posts
  •  
    Malaysia

Posted 23 April 2013 - 06:48 AM

Fixed and working.

Thanks!



#65 aylward

aylward
  • Members
  • 2 posts
  •  
    United States

Posted 25 March 2016 - 01:01 PM

Yes, it should work. However, there's an irritating problem:

When Windows detects an iSCSI Boot Firmware Table (iBFT), and uses it to attach to an iSCSI target, it will wait for a long time (60-120 seconds) for the boot disk to appear. When you are using wimboot, the boot disk is a virtual disk which ceases to exist the moment that the Windows kernel starts up. Windows will therefore sit for a long time waiting for a boot disk that is never going to show up. Eventually it should time out and give up. On a normal system boot, you would see a STOP 0x0000007b if this happened. In this case, you already have everything loaded from boot.wim, so the system will be able to continue to run the installer.

I have not managed to find any sensible way around this annoying delay. I did consider changing wimboot to generate a virtual ISO rather than a virtual HDD; this might be able to fix the problem. (If anyone wants to fund this piece of work, please get in touch.)

In the meantime, be patient and you should eventually see Windows drop through and launch the installer.

Michael

Hello mcb30!

Are you available to accept funding for a small project? I need a thin clients to boot over the internet so that they can run Win embedded standard 7 as their OS. 



#66 mcb30

mcb30

    Newbie

  • Members
  • 22 posts
  •  
    United Kingdom

Posted 25 March 2016 - 03:58 PM

Hello mcb30!

Are you available to accept funding for a small project? I need a thin clients to boot over the internet so that they can run Win embedded standard 7 as their OS. 

 

Yes, I can probably take on that project.  Please contact me directly via e-mail (using this username @ipxe.org).

 



#67 aylward

aylward
  • Members
  • 2 posts
  •  
    United States

Posted 27 March 2016 - 12:23 AM

Yes, I can probably take on that project.  Please contact me directly via e-mail (using this username @ipxe.org).

Did you get the emai I sent you?







Also tagged with one or more of these keywords: http, winpe, ipxe, wimboot, ramdisk

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users