Jump to content











Photo

iPXE, WImboot and multi platform (pcbios/efi/i386/x86_64)

ipxe wimboot pcbios efi

  • Please log in to reply
9 replies to this topic

#1 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2105 posts
  • Location:Nantes - France
  •  
    France

Posted 31 October 2017 - 06:52 PM

Sharing a iPXE script (using wimboot) I am using these days along with Tiny PXE Server to boot winpe over the network on multiple platform : pcbios i386, pcbios x86_64, efi i386, efi x86_64.

 

Tiny PXE Server is serving by default pcbios ipxe.pxe and also, depending on the client architecture, serving the matching ipxe efi version.

 

See below my config.ini and a custom wimboot.ipxe script.

[dhcp]
proxydhcp=1
httpd=1
bind=1
root=\files
filename=ipxe.pxe
altfilename=wimboot.ipxe
[arch] 
00006=ipxe-i386.efi 
00007=ipxe-x86_64.efi 
00009=ipxe-x86_64.efi
#!ipxe
#more about wimboot tips and tricks : http://ipxe.org/wimboot
set boot-url http://${dhcp-server}
#note : we are not going to use cpuid/arch
cpuid --ext 29 && set arch x64 || set arch x86
echo ${arch}
echo ${platform}_${buildarch}
goto ${platform}_${buildarch} || goto unknown
  :pcbios_x86_64
  kernel ${boot-url}/wimboot
  initrd ${boot-url}/BOOTMGR.EXE  bootmgr.exe
  initrd ${boot-url}/BOOT/BCD         BCD
  initrd ${boot-url}/BOOT/BOOT.SDI    BOOT.SDI
  initrd ${boot-url}/SOURCES/x64/BOOT.WIM BOOT.WIM
  boot
  :pcbios_i386
  kernel ${boot-url}/wimboot
  initrd ${boot-url}/BOOTMGR.EXE  bootmgr.exe
  initrd ${boot-url}/BOOT/BCD         BCD
  initrd ${boot-url}/BOOT/BOOT.SDI    BOOT.SDI
  initrd ${boot-url}/SOURCES/x86/BOOT.WIM BOOT.WIM
  boot
  :efi_x86_64
  kernel ${boot-url}/wimboot
  initrd ${boot-url}/bootx64.efi	bootx64.efi
  initrd ${boot-url}/EFI/MICROSOFT/BOOT/BCD         BCD
  initrd ${boot-url}/BOOT/BOOT.SDI    BOOT.SDI
  initrd ${boot-url}/SOURCES/x64/BOOT.WIM BOOT.WIM
  boot  
  :efi_i386
  kernel ${boot-url}/wimboot.i386
  initrd ${boot-url}/bootia32.efi	bootia32.efi
  initrd ${boot-url}/EFI/MICROSOFT/BOOT/BCD         BCD
  initrd ${boot-url}/BOOT/BOOT.SDI    BOOT.SDI
  initrd ${boot-url}/SOURCES/x86/BOOT.WIM BOOT.WIM
  boot    
 :unknown
 echo Unknown platform ${platform}_${buildarch}


  • ktp and nguyentu like this

#2 nguyentu

nguyentu

    Member

  • Members
  • 85 posts
  •  
    Vietnam

Posted 01 November 2017 - 06:00 AM

Thanks but I failed to boot WinPE 32-bit in UEFI 32-bit mode.
 
From the answer here, I think we need to compile a 32-bit wimboot. But I do not know how to compile it. Can you help me compile it?
 

 

If your EFI is 32 bit than you must also run 32-bit efi version of wimboot.

 

 

  • erwan.l likes this

#3 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2105 posts
  • Location:Nantes - France
  •  
    France

Posted 01 November 2017 - 10:28 AM

 

Thanks but I failed to boot WinPE 32-bit in UEFI 32-bit mode.
 
From the answer here, I think we need to compile a 32-bit wimboot. But I do not know how to compile it. Can you help me compile it?
 

 

 

 

 

Good catch !

 

I have corrected the first post to reflect on wimboot.i386.

Wimboot.i386 is now also in pxesrv.zip


  • nguyentu likes this

#4 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2105 posts
  • Location:Nantes - France
  •  
    France

Posted 01 November 2017 - 11:14 AM

Not entirely related to wimboot over different platforms, but since latest wimboot version (2.6.0), you can inject files in the wim file on the fly.

 

You can provide additional files to wimboot. These files will appear within the X:\Windows\System32 directory. For example:

kernel wimboot
initrd winpeshl.ini winpeshl.ini
initrd startup.bat startup.bat

initrd boot/bcd BCD
initrd boot/boot.sdi boot.sdi
initrd sources/boot.wim boot.wim
boot

You can use this to control the boot process after Windows PE has started. For example, you can use a startup batch file to automatically start the Windows installer from a network share.



#5 nguyentu

nguyentu

    Member

  • Members
  • 85 posts
  •  
    Vietnam

Posted 01 November 2017 - 11:51 AM

Good catch !

 

I have corrected the first post to reflect on wimboot.i386.

Wimboot.i386 is now also in pxesrv.zip

I do not look at the src directory because I think it's just source code.
Thank you!


#6 ZEE

ZEE

    Member

  • Members
  • 81 posts
  •  
    Portugal

Posted 19 hours ago

Hi Erwan...

 

Using grub4dos (no ipxe)

 

# With wimboot 2.00 I used this menu entry... and worked OK (notice the bootmgr)

title WinPE32
    kernel /sys/wimboot
    initrd @bootmgr=/boot/bootmgr @boot.sdi=/boot/boot.sdi @bcd=/boot/wimboot-bcd @boot.wim=WinPE32.wim
 

 

# moving to wimboot 2.60 i had to change to

title WinPE32
    kernel /sys/wimboot
    initrd @bootmgr.exe=/boot/bootmgr.exe @boot.sdi=/boot/boot.sdi @bcd=/boot/wimboot-bcd @boot.wim=WinPE32.wim

 

* had to find a bootmgr.exe (used the one from spam)

* and now I get some random problems (freezing, etc.) when winpe gui appears

 

?any thoughts on why bootmgr does not work as used to??

?does this bootmgr.exe works also for a 64 bit winPE ??

?is there any advantage booting ipxe and then wimboot instead of the above (simple) format ??

?any advices (always welcome) on this kind of pxe boot ??



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13923 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 hours ago

@ZEE

Bootmgr and bootmgr.exe are actually (almost) the SAME file.

BOOTMGR is bootmgr.exe with pre-pended a real mode stub.

 

Basically if you have BOOTMGR you can make a bootmgr.exe from it by simply removing this stub, see (reading between the lines):

http://reboot.pro/fi...ls-bootmgrntfs/

 

AND read the documentation:

http://ipxe.org/appn...ot_architecture

 

 

Extracting bootmgr.exe

As wimboot reads each file from the CPIO archive, the file's virtual filename is matched against a list of special names to see if it needs special treatment:

bootmgr.exe: Set this as the file to execute at the end of the boot-loader initialization.

bootmgr: Try to extract bootmgr.exe from this compressed bootmgr file, unless a bootmgr.exe was already supplied.

*.wim: Try to extract bootmgr.exe from the static path \Windows\Boot\PXE\bootmgr.exe within the supplied WIM image, unless a bootmgr.exe was already supplied.

NOTE: The ability to extract bootmgr.exe from the WIM image was added to wimboot v2.2.0. It is a very convenient feature that lets you skip having to explicitly supply the bootmgr.exe file explicitly.

NOTE: If no bootmgr.exe is found, wimboot exits.

 

Since 2.2.0 Winboot should be able to get the bootmgr.exe from within the .wim (of course if it is there).

 

:duff:

Wonko



#8 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2105 posts
  • Location:Nantes - France
  •  
    France

Posted 9 hours ago

Wimboot had some issues in the past with the latest bootmgr format but latest versions should be able to handle it all.

 

As for iPxe versus Grub4Dos boot loaders : they are just both great.

But iPxe focus is about netbooting while Grub4Dos "only" provides pxe support.

 

If you are all about net boot, iPxe should be the preferred choice.

Not saying it will address your issues (i.e wimboot 2.x working vs wimboot 2.6 not working).

 

Note that there could be a similar discussion between wimboot versions and pxelinux : not that simple.



#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13923 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 8 hours ago

As for iPxe versus Grub4Dos boot loaders : they are just both great.

But iPxe focus in around netbooting while Grub4Dos "only" provides pxe support.

It's curious how I would say that Grub4dos is a general, all round, boot manager (though limited to BIOS) while iPxe is focused "only" on netbooting. :dubbio:

 

To me having command line access to the (pd) device is a good half of the fun:

http://diddy.boot-la...s/files/pxe.htm

 

iPXE (besides the specific wimboot tool, that provides a nice way of booting PE's) has IMHO (besides the support for stupid UEFI) the advantage of using other protocols (faster) than TFTP like, HTTP, iSCSI, AOE.

 

The other advantage (capability of booting off the Internet) is IMHO only a (nice :) BTW) useless feature that noone (or next to noone) in his right mind will ever use, set apart for fun experiments, compare with the recent (only seemingly unrelated) topic about Astralboot:

 

http://reboot.pro/to...as-boot-server/

 

:duff:

Wonko



#10 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2105 posts
  • Location:Nantes - France
  •  
    France

Posted 7 hours ago

It's curious how I would say that Grub4dos is a general, all round, boot manager (though limited to BIOS) while iPxe is focused "only" on netbooting. :dubbio:

 

To me having command line access to the (pd) device is a good half of the fun:

http://diddy.boot-la...s/files/pxe.htm

 

iPXE (besides the specific wimboot tool, that provides a nice way of booting PE's) has IMHO (besides the support for stupid UEFI) the advantage of using other protocols (faster) than TFTP like, HTTP, iSCSI, AOE.

 

The other advantage (capability of booting off the Internet) is IMHO only a (nice :) BTW) useless feature that noone (or next to noone) in his right mind will ever use, set apart for fun experiments, compare with the recent (only seemingly unrelated) topic about Astralboot:

 

http://reboot.pro/to...as-boot-server/

 

:duff:

Wonko

 

Indeed, it was my point : these days, IMHO, iPxe is "THE" bootloader you want to use if you are after booting over the network.

The (pd) device is a nice to have but still of limited use (compared to iPxe).

 

Now about Astraboot, I did not have time yet to comment : yes booting of the internet is "bold" to say the least but actually when about installing over the network, these days, I myself spare myself the download of the whole ISO and install it straight over internet combined with pxe boot.

 

Tiny PXE server can help you do that (amongst other similar software I guess): no files (i.e not a few files but actually 0 files) need to sit on your LAN to install a few linux distros.

Fire up TPS, setup a few fields, boot your "to be installed" device and go thru the (netboot) installation steps, all over HTTP.

 

This way you always use an online, trusted, and updated repo and I am not worrying about these important repo's such as http://releases.ubuntu.com/ : they will just not disappear from planet earth.

I trust these to be always up in the air, hosted by some resilient cloud service provider.

 

but I am deviating from the main topic there...






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users