Hiren BootCD 1.0.2

george1421

@garthhess I need to update that tutorial for hirens. It seems like they changed the structure of the wim file since the tutorial was created.

Take a look at this post. I was able to capture the error: https://forums.fogproject.org/post/144293

The root of the issue is you need the latest version of wimboot 2.7.3 that understands the compression of the wim file.

Now you might still get an error about bootmgr.exe. If you do I have a fix for that too.

garthhess

@george1421 said in Hiren BootCD 1.0.2:

wimboot 2.7.3

I replaced the wimboot file from the wimboot-2.7.3.zip download, does the same thing, also, I’m booting UEFI with the ipxe.efi if that makes any difference?

george1421

@garthhess Ok lets try sending that wim file via http not tftp. It might be timing out.

for RHEL/Centos cp /tftpboot/os/Hiren101/boot.wim /var/www/html
for Debian/Ubuntu variants cp /tftpboot/os/Hiren101/boot.wim /var/www

Now lets update this line in the ipxe menu configuration.

imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim

to this

imgfetch --name boot.wim http://${fog-ip}/boot.wim boot.wim

Understand I really didn’t think this through, but it should be pretty close to actually working. The apache server is much better suited to serve out larger files than the tftp server.

garthhess

@george1421 said in Hiren BootCD 1.0.2:

imgfetch --name boot.wim http://${fog-ip}/boot.wim boot.wim

Well it loads ALOT faster, but still does the same thing.

mikr

I managed to get Hiren BootCD 1.0.2 working on UEFI (Only tested in Hyper-V 2019 Gen. 2) by using the following config:

set tftp-path tftp://${fog-ip}
set http-path http://${fog-ip}/images/tools/hbcd102
kernel ${tftp-path}/win/wimboot gui
imgfetch --name bootmgr.exe ${http-path}/bootmgr.exe bootmgr.exe
imgfetch --name bootx64.efi ${http-path}/efi/boot/bootx64.efi bootx64.efi
imgfetch --name BCD ${http-path}/boot/bcd BCD
imgfetch --name boot.sdi ${http-path}/boot/boot.sdi boot.sdi
imgfetch --name boot.wim ${http-path}/sources/boot.wim boot.wim
boot || goto MENU

The key was to add:

imgfetch --name bootx64.efi ${http-path}/efi/boot/bootx64.efi bootx64.efi

Tiha

@mikr Thanks, I managed to get it working on UEFI with your settings, but my problems is, that there aren’t all the apps after it boots succesfully. Only those which have a link to Program files. Those in the Programs folder in the ISO, aren’t available. For. ex: only HDDScan and Test Disk are available in the HDD Diagnostic Tools. Any ideea how to solve this?

George

Hi

I can confirm also that Hirens boot cd it loads but i can not see the programs at all.
The apps of Hirens boot cd is not there.

BDiddY

@george
the “Programs” folder is not part of winPE, it stays back on the CDrom iso on the Y: drive. If you boot the ISO thru a console - you get to keep the Y: drive. If you boot the ISO thru PXE, control is turned over to Hiren winPE process and you lose access to the Y: drive.
To make the Y: drive available from a PXE boot: I edit Hiren’s boot process inside the boot.wim file and map the Y: drive to a network share after winpe initialize but before Hiren process initializes. You must copy folder ‘Program’,‘CustomDrivers’, and HBCD_PE.ini to the network share.

cplemaster

@BDiddY @George

@BDiddY, I made this account just to reply here.

I don’t mean to sound rude, but it would be very much appreciated in the future if you explain what exactly you changed instead of just saying “I edit Hiren’s boot process inside the boot.wim file and map the Y: drive to a network share after winpe initialize but before Hiren process initializes.” when describing the fix. This is extremely vague and doesn’t offer any help to users who are trying to find the solution. I gave myself a headache trying to figure out what exactly was changed that fixed it for you based on your comment. I ended up finding it with grep, so I’m posting it here:

The Y:\ drive is indeed on the root of the CD image and does not get loaded into PXE since you’re effectively skipping over that and booting directly to the WIM in a subfolder. You need to have the directories and files that are traditionally mounted into Y:\ (which are Programs,CustomDrivers,HBCD_PE.ini) placed somewhere else accessible to the image. An actual example solution to this issue is to:

Mount the WIM with DISM
Open the file “windows\system32\pecmd.ini”
Under the section _SUB_PreShell at ~line 36, add a line just after the first line in this section (that contains EXEC @!%WinDir%\System32\winpeshl.exe) containing a command that mounts Y:\ to a path accessible to the image. If you do not do this, Y:\ will not be mounted and everything else in this initialization script will fail silently.
Commit your changes and copy the new boot.wim to the PXE path you’re defining for Hiren.

In my preferred method, I chose to simply make a folder inside the root of the boot.wim titled “Y_drive”, copied Programs,CustomDrivers, and HBCD_PE.ini into it, and added the following line to that section:

_SUB PreShell
	EXEC @!%WinDir%\System32\winpeshl.exe
	EXEC =@!%WinDir%\System32\subst.exe y: X:\Y_drive // NEW COMMAND

This would just create a Y:\ mount that points to a local directory inside X:\ . I did not want to host these files on a network share since I had no intention of changing the contents of Hiren’s included programs or startup items. I just wanted the thing to work. This will add roughly 1GB to the .wim size, just be warned. If you wish to use a network share as BDiddY described, then simply substitute the command for another method of using SMB, eg. net use with your network share path, and credentials if needed.

Using a simple folder substitute as I described above fixed the programs being missing after booting from PXE since they are now included in the WIM image being loaded. I also commented out the line that triggers startup.mp3 to play (in the same file at line ~346) because it’s an obnoxiously loud sound that turns my teams’ heads every time I use this tool.

I hope this prevents the same frustration for new users that I went through for this since I know almost nothing about WinPE processes or specific Hiren’s startup workflow.

george1421

@cplemaster Excellent explanation of how to go about solving this.

I can tell you that pxe booing large files over the tftp protocol can take time. You can and probably should download the wim file over http protocol. Its much faster and scales better than tftp.

Such as in this parameter block

set tftp-path tftp://${fog-ip}
set http-path http://${fog-ip}/images/tools/hbcd102
kernel ${tftp-path}/win/wimboot gui
imgfetch --name bootmgr.exe ${http-path}/bootmgr.exe bootmgr.exe
imgfetch --name bootx64.efi ${http-path}/efi/boot/bootx64.efi bootx64.efi
imgfetch --name BCD ${http-path}/boot/bcd BCD
imgfetch --name boot.sdi ${http-path}/boot/boot.sdi boot.sdi
imgfetch --name boot.wim ${http-path}/sources/boot.wim boot.wim
boot || goto MENU

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/10

cplemaster

@george1421

Absolutely, I already had http serving in-place so the additional 1GB size result was negligible impact. Thanks for the additional insight, however.

Happy to help out, I just noticed a majority of posts about this ended with users reporting Hiren over PXE was “solved” by simply updating their wimboot version, with no other notes. While it does fix booting it, it is only part of the solution. It’s necessary to do that but it is not a complete fix. You need the Y:\ mount fixed or else the booted ISO is still heavily broken. Hopefully this helps some people out. HBCD is a great Swiss Army knife.

Hiren BootCD 1.0.2

174

11.6k

17.1k

154.6k