Can't boot to Hirens ISO from IPXE Menu
-
@mstephens
ls -la /tftpboot/os -
This post is deleted! -
-
@mstephens Show me the parameters you have setup in the iPXE menu.
-
bcd is lowercase because that’s how it presents in the dir
BOOTMGR is uppercase because that’s how it presents in the dir -
@mstephens I’m hoping the pictures are mixed up on the orders. This is should be what the parameters look like
set tftp-path tftp://${fog-ip}/os set pe-path ${tftp-path}/Hiren101 kernel ${tftp-path}/wimboot gui imgfetch --name BCD ${pe-path}/BCD BCD imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim boot || goto MENUThat boot after loading the wimboot is what is causing the start before imgfetch is executed.
-
@george1421
They are out of order, here is a copy
-
@mstephens Hmm I can’t explain why its not loading wimboot because its in the right spot and missing out on the imgfetch commands. I guess the masked IP address is the address of your FOG server?
From a windows computer, if you install the tftpclient feature and drop the firewall for testing, can you use tftp to get wimboot from the FOG server?
-
Can’t seem to get the file from windows. The machine is on the same subnet so nothing passes the firewall. Error ‘connect request failed’
-
It is the FOG server IP
-
@mstephens said in Can't boot to Hirens ISO from IPXE Menu:
Can’t seem to get the file from windows.
From the fog server can it get the file from itself?
On the windows computer, if you did not drop the firewall or grant the tftp program access that is probably the problem. tftp is much like ftp in that there are two communication channels setup. “Command” from the windows to FOG and “Data” from FOG to windows computer.
-
So i got it to load through. just moved wimboot to the root and back and it worked on restart. . . But now it just loads the imgfetch then flashes the following screen, and proceeds to windows.
-
-
@mstephens so that’s different from what I understood. This is working as it should.
Does the boot.wim file get transferred? Or does it stop?
-
It finishes, then returns to booting windows (virtual drive has windows on it)
-
@mstephens Well I set this up in the test bench and I get the same results. Its possible that everything loaded in memory is larger than 2GB and that is causing things to abort.
Its not a timing issue because I switched loading boot.wim over to http instead of tftp and the load happens in about 8 seconds now.
It appears the booting of wimboot is crashing which returns us back to the iPXE menu then onto refind.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Ok I’ve spent about as much time as I can on this issue. The root of the issue is the way the boot.wim file is created.
I can get it to boot in bios mode if I download the latest wimboot from the github site: https://github.com/ipxe/wimboot/blob/master/wimboot the current zip file doesn’t contain version 2.7.3. The zip file contains 2.6.0. The version 2.6.0 doesn’t understand the maximum compression mode the boot.wim has been compressed with. It appears in bios mode wimboot 2.7.3 understands this and will boot into recovery software. I tried the same in efi mode and still getting it failing to boot wimboot with that boot.wim. The instructions in the tutorial page is right, its that Hirens boot.wim file that is the issue.
This is what lead me to trying something different.
-
Is there a restriction in UEFI for anything using over 2gb memory?
-
@george1421
Thank you George, I’ll give it a go! Appreciate it.
