Testers

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

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.

@snaggel said in After update to 1.5.3 node offline and unable to PXE boot.:

i ran that command the was no such file or directory. however there is one for /tftpboot/ipxe.efi

@Sebastian-Roth said in After update to 1.5.3 node offline and unable to PXE boot.:

I would start with the obvious: run ls -al /tftpboot/ipxe.efi on your FOG server to see if the binary has been populated properly

What am I missing here?? Sebastian’s command should have listed that file out and its file size.

As a test if you install the tftp client feature in windows, you can test download that file to your windows computer via command line too. The command would be something like tftp <fog_server_ip> get ipxe.efi . to transfer the ipxe.efi boot file to your computer. We are only interested in knowing if the file is transferred or not.

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

Couple of things to check:

1. Is the original machine in BIOS or UEFI mode?
2. Is the target machine in BIOS or UEFI mode?
3. If both are in UEFI mode, you may have to manually add the boot option in the UEFI of the target machine.

Here is a guide I’m working on to help people who need to build custom ipxe boot kernels: https://forums.fogproject.org/topic/12121/compiling-ipxe-boot-kernels

[Edit] Well I feel a bit foolish that I reinvented something that had already been created. [/Edit]

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

@quinniedid
I just changed mine to

menuentry "windows" {
Volume SYSTEM
loader \EFI\Boot\bootx64.efi
enabled
}

And it was working. However my local refind suddenly stopped working. Which is pretty confusing considering nothing was changed and it worked before. Maybe there was something in a recent windows update that somehow affected this? It’s a bit of a stretch though. I’ll keep testing things.

@quinniedid I’m actually getting the same thing now too. I promise it was working, it was a thing