Hello,

i recently constructed a dual boot image with Linux CentOS 7 and Memtest86 (Passmark).
The initial master image worked as intended with minimal input. I basically only added a grub boot entry for Passmarks .efi-file, but it works as intended.

After deploying this image via fog to 12 identical servers the servers’ grub entry for Passmark broke somewhat depending on what bootloaders are involved.

When booting directly from BIOS to disk (grub), then everything still works as intended.
But a problem arises when we PXE boot into the fog menu and exit with rEFInd to boot from disk.
rEFInd correctly boots into the grub boot loader that is configured on disk. grub in turn can then boot CentOS as normal but it cannot boot Passmarks .efi-file.
Error Message: “sector sizes of 1 bytes aren’t supported yet.”

When we then exit out from grub back into rEFInd, reFind can then boot any ondisk .efi-Files without issues.
Curiously when booting the standard grub fallback entry that is preconfigured from the CentOS installer via rEFInd and exit grub again into a reboot, then the entire problem vanishes permanently.

From then on there are no further boot problems regardless of what boot loaders are used and in what order. It does not matter whether passmarks efi-file has been loaded at any prior point. It only matters whether the grub centos fallback option has been loaded by rEFInd.

This behaviour is consistent over 12 identical servers and multiple reboots each.

Our FOG-Server is inside a VM so we can easily disconnect it to reboot into another ondisk OS to workaround this entire issue without manually handling each bootloader. And for our next image iteration i will try to swap out the ondisk grub for rEFInd and see if that brings any weird behaviour.

Do any of you know if there is any interaction between rEFInd and grub that might explain this behaviour?

@Tom-Elliott
Thanks, for all the input.
I’ll see if i can find some sensible solution for my setup.

@Tom-Elliott
Thank you for your detailed response.
This makes a lot of sense. But then how does FOG decide which disk to use when multiple options are available?

In the world of SSD drives, though, things get a bit more complicated but follow similarly to USB/SATA in that the speed of the drive and the PCI controller presents the “order” of the drive, but this boot can be this device, and that boot can be another device.

So even if the only media present in the system are SSDs it is not consistent which drive slot in the physical enclosure is referenced by udev’s /dev/sdX naming scheme? Depending on how fast each drive was initialized on startup.

Would it be feasible fo me to create a udev rule for my FOS instance by compiling the kernel myself?
https://docs.fogproject.org/en/latest/kb/reference/compile-fos-kernel/

In theory i should be able to create a udev rule that creates a symlink for arbitrary SATA-SSDs that points to a predefined name.
If the system does not contain more than one SATA-SSD the symlink should be unique and in turn could then be used as the Primary Disk in FOG’s Web GUI without worrying about mistakenly using a USB-Device?

But then i guess this is probably more trouble than it would be worth. And it would at best only be as reliable as my udev rule.

Probably makes more sense then to incorporate the application that runs on the USB-Sticks into a dual boot image that we deploy with FOG.

Aside from this

Hello,

I have some questions as i would like to find a foolproof way to exclude USB-Sticks when selecting deployment targets. That is besides just unplugging them as this would offer us a big quality of live improvement.

If multiple disks are found on the system, which one will be chosen for image deployment when no primary disk is specified for the host?
Is it just the first that is named by udev?
As far as i know udev lists disks in the same order in which they are presented by the disk controller. Is it therefore reliable to expect SATA/SAS Disks before USB attached filesystems?

While deploying an image. If mutliple disks are available as targets, are disks that are too small for the image automatically disregarded?

If a disk is selected that is too small for the desired image, then the partition table will be deleted before the imaging tool aborts with an error. Is this correct?

Best Regards

@george1421

Just tested it and it works correctly.
Thank you for your effort.

For other beginners with iPXE like me:
This is the relevant documentation for the flow control.
https://ipxe.org/scripting
With examples at
https://ipxe.org/examples

@george1421 Thank you for your writeup. That information helps a lot.
Tough it seems that the if-clause is not supported in that context, or that the syntax is off.

After selecting the memtest64 option in the iPXE-Menu i got an error message of: “if: command not found”
Without the if-clause using only the efi instructions this solution worked flawlessly. Thank you for your help in that.

Should this Parameters section in theory support these kinds of flow control?
Or is it expected/safer to call an additional script with the menu item to let that script then work through the logic?

Hello,

I’d like to update the version of memtest 86+ that comes preinstalled with fog and still be able to schedule memtest as a task from the Web GUI.
The currently newest version is 6.20 and supports UEFI PXE Boot.
fog version 1.5.10

I tried replacing the memtest.efi-file in /fogproject/packages/web/service/ipxe with the newer one (memtest64.efi) and editing the memtest kernel name in the general fog settings.

But this leads to ‘Exec formatting Errors’ in iPXE.
What are the config-Files that might have to be edited and which files need to be placed where on the (freshly installed) fog-server?

BR
Chris