rEFInd PXE booting issue
quinniedid last edited by quinniedid
We have a HP ProDesk 600 G3 and it is failing to PXE boot and we are getting stuck on the rEFInd - Initializing page. The OS boots just fine if we do not network boot. We have made several changes to refind.conf to try and get around this but have been unsuccessful.
This refind.conf is working great on our other new HP Pavilion 570-p015z, but it seems that we might be running into hardware issues.
We have tried making some changes that was done from this post: https://forums.fogproject.org/topic/11897/boot-loop-after-imaging-uefi/29
We are running fog 1.5.3
bzImage Version: 4.16.6
bzImage32 Version: 4.16.6
Let me know what other information you would like me to gather.
Thank you for the help. It is greatly appreciated.
@JJ-Fullmer Yeah I started a new post with what I did, I had to piece together some stuff to get the whole shebang to work.
@psycholiquid Have you tried reverting the FOG Server refind version to 0.11.0 and older? That’s the current workaround.
Toss me in the group of people with HP ProDesk 400s All of mine are acting this way now.
@quinniedid I haven’t heard from the rEFInd developer since the initial contact. As soon as I know something I’ll post it here.
@george1421 I was able to change that file to an earlier version and it appears to have fixed our UEFI issue on our newer HP PC’s
@JJ-Fullmer Please let me know what I can provide in testing if needed
- Just download the version you are interested in.
- Then grab the refind.efi file from the zip file and…
/var/www/html/fog/service/ipxe/refind.efi to /var/www/html/fog/service/ipxe/refind.efi.sav
mv /var/www/html/fog/service/ipxe/refind.efi /var/www/html/fog/service/ipxe/refind.efi.sav
- Copy the refind.efi file to /var/www/html/fog/service/ipxe
@george1421 @JJ-Fullmer I am more than happy to do some testing. Please provide me instruction on what is needed and the debug information that is needed and I can provide some time to testing. Thanks for all of your help.
And to answer the question I am unsure how to change the rEFId version in FOG to make this work for this hardware but we do have a workaround by using BIOS for now till we get this issue resolved.
@george1421 I meant to put that I volunteered as tribute when I quoted his reply.
I’m sure he’d appreciate more testers as well if anyone’s interested.
@jj-fullmer Very nice and quick reply from the rEFInd Developer (they are almost as fast as the FOG Developers to respond).
Do you have the time to work with the refind developer to figure out the root of the issue, since you have the hardware? The results will help both FOSS projects.
@george1421 The developer has replied, I have quoted it below
Thanks for the bug report. Upon reading the thread, I think the bug may be related to changes I made to work around problems caused by changes to the way macOS stored its files on APFS volumes, as noted in the release notes for version 0.11.1:
: As a follow-on to the preceding change, I discovered that compiling
: rEFInd with GNU-EFI resulted in a failure to properly track some
: files on APFS volumes. I don’t know if this failure reflected a bug
: in Apple’s EFI, in GNU-EFI, or in rEFInd; but I changed the way
: rEFInd tracks boot loader files internally to work around the
: problem. Although I’ve tested this version on an unusually wide
: number of computers, it’s possible that this change will introduce
: new bugs. Thus, if you upgrade and have problems with boot loaders
: not being detected or not launching, dropping back to version 0.11.0
: may be worth trying. (Be sure to contact me with a bug report, too!)
I can look over these code changes for any obvious bugs, but tracking this down may require testing with debug versions that display debugging data. If you or somebody else who’s affected can help with that, it might speed up the process.
FWIW, some of the reports mentioned HP EliteDesk computers. I happen to own an EliteDesk 705, and I have NOT seen the problem on it. Thus, I suspect that the problem appears as an interaction with a very limited set of EFIs and/or something quirky about the partition table, filesystem, or other system-specific setup. This isn’t to say the bug exists in some other component, but it’s likely manifesting only in some rare circumstance.
In the meantime, using version 0.11.0 makes sense as a workaround.
@Developers Please be aware of JJ Fullmer’s post on issues with refind 0.11.1 and 0.11.2. Reverting back to 0.11.0 appears to have addressed his issue with HP.
@JJ-Fullmer Great find!!, please let us know what the rEFIn’d developers respond with.
@quinniedid I changed my fog’s refind.efi out with rEFInd 0.11.0 (The first version I used for local installs) and it started working for me too. I think there must be some sort of bug in 0.11.1 and 0.11.2 that affects HP pro/elite Desk systems. I am reporting it to the developer of rEFInd.
So would you say your problem is now fixed by reverting to the older version of rEFInd? Or are there still some different problems happening?
@quinniedid Hmmm that is interesting for sure. Now that I think about the versions, maybe some of my problems showed up when I updated things to the most recent refind.
However I noticed another thing, which may or may not be related to the version of rEFInd. In the HP bios boot options, when I installed my local refind, it used to show a normal uefi boot option to the disc drive, a windows boot manager option, and my custom refind option. Now it seems that the custom refind option overrides the other options.
Perhaps windows 10’s bcdedit is now able to control hp bios boot options? I’m just spitballing here. But perhaps refind can’t find any boot loaders because the bios/firmware doesn’t see those boot options either. It wouldn’t fully explain why the fog rEFInd isn’t seeing the boot options during its scan but it could be something. Another possibility is a csm type of issue (I think that’s the right acronym). Where you have both legacy and uefi boot options enabled. I currently disable legacy completely, but refind has the ability to scan for those legacy options, perhaps re-enabling legacy options will allow it to find those and maybe that will help it find the uefi options as well. Gonna keep playing with it and see if I can find a clear answer. If None of these combinations of things work then I’m gonna say you’re right and the newest version of refind is what breaks things.
@JJ-Fullmer We have found something very interesting. If we use rEFInd version 0.10.9 we are able to get the menu and we are able to select Windows from there with no issues. If we go to 0.11.X or higher we run into issues of it not finding Windows and would get stuck on “Scanning for boot loader”. We even went so far to copy the refind.conf file that was on fog our to our rEFInd USB and it booted to Windows without any issues. We have also tried the other things that you have posted with no further of a result.
@george1421 So now that we finally had access to the menu and to the shell we were able to issue the command that you requested
Sets the volume that's used for subsequent file accesses (by icon and loader, and by implication by initrd if loader follows volume). You pass this token a filesystem's label, a partition's label, a partition's GUID, or a volume number. A filesystem or partition label is typically displayed under the volume's icon in file managers and rEFInd displays it on its menu at the end of the boot prompt string. If this label isn't unique, the first volume with the specified label is used. The matching is nominally case-insensitive, but on some EFIs it's case-sensitive. If a filesystem has no label, you can use a partition GUID number. You can also use a volume number followed by a colon, such as 0: to refer to the first filesystem or 1: to refer to the second. The assignment of numbers is arbitrary and may not be consistent across boots, though. It might change if you insert an optical disc or plug in a USB flash drive, for instance. If this option is not set, the volume defaults to the one from which rEFInd launched.
It’s possible I read too much into it and assumed that the “aribtrary” part had to do with the boot order in BIOS, maybe it has more to do with how refind interprets it instead?
The funny part is that the point of refind is that it’s supposed to scan all the volumes for you to solve this very problem. So something is very weird here.
@quazz Where did you read the numbering labels are based on bios boot orders? If that is indeed the case one can control boot order to some extent and that would work. You would just want to make sure usb and disc options were always lower on the list, maybe even disabled and just utilize refind to boot to them.
@jj-fullmer Reading over the docs, Volume uses the filesystem label.
Isn’t this label typically “System Reserved” (on English Windows installations)?
It also mentions it’s nominally case insensitive, but can be case sensitive on certain UEFI implementations.
It appears you can also you use the filesystem number, so you could do
Volume 0:presumably, however it seems that this is based on the boot order in UEFI and may be subject to change on subsequent reboots and so isn’t likely to be reliable.
@quinniedid Scratch that, it worked once then it failed the second time. This is really odd. Maybe there is a new feature in HP uefi settings that is conflicting with refind. Gonna toy with it for a bit.