What is the netmask of the DHCP server and the PXE client (considering the 192.168.2.x and 192.168.3.x addresses of your screenshots)?
Asked in another way: is there a relay agent between the two?
Also: is Secure Boot disabled on the client?
What is the netmask of the DHCP server and the PXE client (considering the 192.168.2.x and 192.168.3.x addresses of your screenshots)?
Asked in another way: is there a relay agent between the two?
Also: is Secure Boot disabled on the client?
What is the netmask of the DHCP server and the PXE client (considering the 192.168.2.x and 192.168.3.x addresses of your screenshots)?
Asked in another way: is there a relay agent between the two?
Also: is Secure Boot disabled on the client?
I did some testing with 0.13.2 and 0.11.4 and BOTH did not work.
0.11.4 files are dated “12.11.2018 21:13:xx”, size of the refind_x64.efi file 208 776 Bytes.
The binary in the FOG 1.5.5 package (refind.efi) is dated “15.11.2018 20:42:17”, size 205 192 Bytes.
Those are not the same files.
@peterl said in REFInd-Initializing - hangs:
Your issue with rEFInd is because of HPs EFI.
I have exactly the same issue with ProDesk 400 for quite some time.
The workaround to get those systems booting via rEFInd was a downgrade of the rEFInd binaries.For me a downgrade to rEFInd out of the FOG 1.5.5 package did the trick.
Path in the ZIP archive: fogproject-1.5.5.zip\fogproject-1.5.5\packages\web\service\ipxe\refind.efi
The binary is dated 15.11.2018
On a Debian system place the file in /var/www/html/fog/service/ipxe
Once as “refind.efi” and a second time as “refind_x64.efi”.
As I’m not allowed to edit my own posts …
I’ve seen this issue on ProDesk 400G5, none the less I think it’s the same problem.
HPs EFI is a real PITA and besides the problem you observed you will (most likely) also stumble upon a changed boot order, once you deployed images to your hardware.
There is a setting for WOL in the “internal devices” section in the EFI, where you most likely will want to setup “PXE” instead of “normal boot”. This way you will be able to remotely work with a machine by shutting it down, waking it up and have it reliably booting to FOG menu/task.
Your issue with rEFInd is because of HPs EFI.
I have exactly the same issue with ProDesk 400 for quite some time.
The workaround to get those systems booting via rEFInd was a downgrade of the rEFInd binaries.
For me a downgrade to rEFInd out of the FOG 1.5.5 package did the trick.
Path in the ZIP archive: fogproject-1.5.5.zip\fogproject-1.5.5\packages\web\service\ipxe\refind.efi
The binary is dated 15.11.2018
On a Debian system place the file in /var/www/html/fog/service/ipxe
Once as “refind.efi” and a second time as “refind_x64.efi”.
I didn’t have time to test the rEFInd downgrade yet but found a workaround for the issue with the missing boot entry in the BIOS.
Rebuilding the BCD obviously solves the “problem” (which only HP BIOSes have).
Recovery process in short:
Still I’m wondering why this is an HP only issue.
Edit: I’m almost sure that “bcdboot C:\Windows /addlast” will also do it but currently do not have a victim to test upon.
Hi,
we’ve got a few FOG deployments out there and we seem to have the same issues with HP hardware on all sites.
The first issue is with rEFInd not booting - I found a thread with a possible solution here: https://forums.fogproject.org/topic/14189/fog-1-5-7-uefi-refind-boot-to-win-10/3
I’ll have to try downgrading rEFInd like this user did and check if it will get going.
My main issue is that AFTER imaging the computers can’t seem to locate the Windows boot loader.
When manually selecting “Boot from file” and pointing to \EFI\Boot\bootx64.efi in the boot selection menu, the Windows installation boots normally.
Also there is no “Windows Boot Manager” entry in the UEFI boot options.
This most likely has nothing to do with FOG itself but with HPs BIOS/EFI implementation.
Same image on Lenovo/Dell hardware (and in the vmWare VM I’m building the image on) works as expected.
Does someone have tips on how to possibly work around this?