rEFInd PXE booting issue

[Quazz]

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

[JJ Fullmer]

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

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]

@jj-fullmer https://www.rodsbooks.com/refind/configfile.html

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?

[quinniedid]

@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

[JJ Fullmer]

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

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

[george1421]

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

[JJ Fullmer]

@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.
–
Rod Smith

[george1421]

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

[JJ Fullmer]

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

[quinniedid]

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

@quinniedid You can get the refind files from here: https://sourceforge.net/projects/refind/files/

1. Just download the version you are interested in.
2. Then grab the refind.efi file from the zip file and…
3. Rename
   /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
4. Copy the refind.efi file to /var/www/html/fog/service/ipxe
5. Done.

[quinniedid]

@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

[JJ Fullmer]

@quinniedid I haven’t heard from the rEFInd developer since the initial contact. As soon as I know something I’ll post it here.

[Psycholiquid]

Toss me in the group of people with HP ProDesk 400s All of mine are acting this way now.

[JJ Fullmer]

@psycholiquid Have you tried reverting the FOG Server refind version to 0.11.0 and older? That’s the current workaround.

[Psycholiquid]

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

[Yeet]

@george1421 Hi, I’m attempting this fix right now and I’m running into an issue. I downloaded the latest version of the zip, and I only see refind_aa64.efi, refind_ia32.efi, and refind_x64.efi. I do not see the refind.efi file in the latest version, or 1 version behind that. Should I just replace the 3 files I listed? or will that cause issues.

[george1421]

@yeet said in rEFInd PXE booting issue:

refind_aa64.efi, refind_ia32.efi, and refind_x64.efi.

on your fog server look in /var/www/html/fog/service/ipxe directory. There will either be refind.efi in there or refind64.efi and refind32.efi.

First of all you can discard the aa64 version of refind because that is for ARM processors.

The others refind.efi is really the renamed refind_x64.efi. And if there is a refind32.efi that is just renamed refind_ia32.efi.

If you correctly rename the files it should work.

FWIW the fog installer installs a script where you can rebuild the current iPXE on the FOG server and not need to do the download and rename bit.