Hi everyone,

I’ve been trying to follow this awesome tutorial (thank you to @george1421, btw ) because it looks promising, and I’ve got my setup partially working as I’m able to boot iPXE and refind, I’m even able to take an image of my added host, I’m able even to boot Windows from the firmware boot menu… However… the default entry in refind (“Boot from hard disk”) is not working, not sure what’s actually running this entry, … but it’s not able to boot the actual hard disk. In fact it has a weird behavior … because apparently that entry is trying to load refind, but you can see in this video it’s not able to fetch refind.conf.

Anyway … I’m a little bit confused … because if I press s to get into de iPXE shell, and run manually

imgfetch http://<my-fog-ip>/fog/service/ipxe/refind.conf
chain -ar http://<my-fog-ip>/fog/service/ipxe/refind_x64.efi

It seems to work… but I have again the very same menu. So … some idea about what could be happening or how may I debug this behavior?

Thank you very much!

PS: I’d suggest some minor fixes for @george1421 tutorial, but it’s a closed topic … so not sure if those might be fixed

@george1421 well, after some tests … The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

Not sure if you’ll edit your tutorial with my suggestions … but I’ll write a little document for myself also … I think the signing process (with sbsign) may be automated in a bash script with a for loop, but your tutorial is still very valuable and helpful. This would be just a minor improvement. However … I think I’m going to write some script to try to automate the whole process, I could send it to you if you are interested in

Thank you again @george1421 and I hope you find also useful my suggestions

Hi @george1421! Thank you for your answer

Well, I think the very same, so not sure if I should repeat the whole process (including FOG initial deployment/install), but sure, this wouldn’t seem a SecureBoot problem if it weren’t because of this setting in the firmware

I can see your firmware hasn’t that Secure Boot submenu, so … not sure how this could be interfering … but I’m having this issue when I set this in Deployed Mode. However, Audit Mode works as I expect, and … according to the description in my screenshot I’d say the proper value for production is Deployed Mode, and this should work in a very similar way Audit Mode does.

So not sure if this has something to do with some kind of network misconfiguration.

The most important fixes I’d suggest to your tutorial are the following, btw:

• You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist
• Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Aside this … the tutorial is so helpful so … congratulations @george1421 and thank you a lot for your answer again.

@Tom-Elliott said in Fog iPXE Menu no input:

Either way, similar to the post about bisect, below, might help us out as well.

I’d need more details, some article or document on how to perform this bisect, but I’m interested in contributing, sure

@Tom-Elliott said in Fog iPXE Menu no input:

@jfernandz next-server comes from the dhcp server option 66 (I think that’s what it is in Windows DHCP at least?)

That said, often when next-server is empty it’s usually because there’s multiple dhcp servers trying to tell the same single client their next-server and it doesn’t know which one to use, so it just goes blank. That’s not to say it couldn’t be a firmware issue, but just expressing my past experiences.

Hmm … my problem isn’t an empty value for next-server, rather … it comes with an IP, but its the DNS server IP address! …

Regarding the keyboard issue … we are working with Dell Precission 3930 Rack machines, but we also have in the same cluster a couple of Dell Precission 7960 Rack machines where I didn’t tested, I can say a couple of days ago, we upgraded the BIOS of the 3930 which are the ones I can detect this issue, that’s why I was guessing this could be a problem between iPXE and upgraded firmware

I’m experiencing the same problem with keyboard input, in fact the keyboard input doesn’t work either till the OS boots, it doesn’t work in Grub, I feel like if iPXE were having a kind of issue with the firmware.

Also I’ve noticed … I’ve had to replace ${next-server} in the ipxescripts files with the actual FOG Server IP as it seems iPXE isn’t able to retrieve this value from the DHCP service in the FOG Server. Not sure if the firmware issues could be causing this also.

@Tom-Elliott Well, sure about the bitlocker point. Regarding the LUKS point I wasn’t actually asking if it’s technically possible, but rather if this feature is currently implemented (partclone/partimage asking your for the LUKS passphrase)

Regarding this point … Now I’m thinking in cryptsetup and LUKS. I’ve noticed CloneZilla is able to ask you for a LUKS volume passphrase to decrypt it before taking the image, may FOG do the same? Apparently with default options FOG just takes the image in raw format, but is there some way to make FOG act like CloneZilla?

Thanks again and sorry for bringing up this topic again.

First of all, sorry for resurrecting this old thread. However … I was experiencing this issue with HP machines with BIOS U62 Ver.01.01.21 07/01/2024.

The only way I was able to workaround the issue is by using refind binaries from FOG 1.5.5 as @PeterL says in their answer:

@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.

FOG 1.5.5

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”.

But I’ve tried with latest rEFInd version from sourceforge as @george1421 points in their answer

@george1421 said in REFInd-Initializing - hangs:

@peterl FWIW the refind files can be located here: https://sourceforge.net/projects/refind/files/

For a very log time FOG shipped with 0.11.0 version of refind. This was a very stable, but old release. Based on the image date you referenced that must be the 0.11.4 release of refind. You might also want to try 0.13.2 (newest at the time of writing). To see if the very latest version of refind works for you.

but even this latest version isn’t able to boot the EFI partition from the internal disk. So weird, not sure how may I help to diagnose this issue for rEFInd project … but I’d like to help. Can’t find a way to increase verbosity for rEFInd despite I’ve tried some config directives in refind.conf

Thank you for this helpful post guys

@george1421 oh, that will be our best alternative for now, sure Anyway I was just trying to think in some possible feature FOG client could implement regarding this, maybe I’ll be willing in the future to contribute to the project though not sure right now if Suspend-Bitlocker will require some kind of authentication

@george1421 than you for your answer, you’re always willing to help

What about the point of implementing, for example, Suspend-BitLocker in the FOG client side?

The TPM point is a good one, but … almost all machines we work with have an “easily” accessible/replaceable TPM hardware module, could just we restore some disk image in a new machine with the TPM of the old one? Would this work?

I’ve noticed available tools for image managin (partclone and partimage) aren’t able to take an image of a disk with BitLocker enabled, I’ve seen that you could use manage-bde in CMD or Disable-BitLocker/Suspend-BitLocker to disable temporarily BitLocker and take the image. However I’m wondering if this process might be automated by the FOG client or I could provide FOG my BitLocker recovery key to make this process of take images of encrypted disk more automatic.

Thank you very much

Not sure why setting the LDAP plugin manually I couldn’t get it working … but I exported the plugin config from an old FOG instance and imported it in the new one and it worked, so I think you can mark this as solved