@Sebastian-Roth everything I’ve found on this issue refers to using the disks uuid to identify which one to apply it to. That doesn’t help us much as every drive on a system would have its own uuid. So how do we identify which is which? I know it doesn’t help anything. Everything from Serial to Pata and nvme aren’t guaranteed to be a persistent naming scheme for Linux. Luckily SATA and PATA seem to follow the channel pattern on how they’re connected and named. With NVME being on a pcie channel this makes enumeration dependent on how fast a disk feels like revealing itself to the system.

@jmason what mode is the sata operation within the bios in?

I’m guessing it’s in raid mode. Is it likely because RAID mode would want at least 2 HDDs regardless of mode of raid that the raid controller is changing how the disks present to the OS?

Essentially, because it wants raid the order in which they’re listed wouldn’t matter to build the array and have things work properly. But because we aren’t in a RAID configuration we are seeing the issue?

@Ginto what about max clients for the storage node itself?

@maouu Can you run the reg delete from the command line as is?

@maouu The FOG Client runs as the SYSTEM user, so yes, it has systems rights to delete a registry key, I would think.

Are you sure that is the location of the key, or is it in HKLM\SOFTWARE\WOW6432Node\TightVNC

I’m not questioning your expertise, but the information would seem to indicate something else.

I suppose you could create the reg, create a batch script to load/run the reg key, and use a “snapinpack” to run on the machine.

There’s too many things to think about here though.

Yeah, too lessen confusion for myself, I called what you call “raw” a “super base” or “base”

Adjusting “base” for whatever I mean.

For example:

Superbase is the base image that ALL machines regardless of who or where the machine sits will start from.

XXXBase is a specific base based from the “superbase”.

Just my thoughts. No real value here!

@maouu Does the key actually exist on the machine?

The error code you received is from the reg delete command itself. If the command runs it only returns two codes.

0 = Success
1 = Failure

There isn’t any information as to why there would be an error so I’m just guessing the key simply doesn’t exist on the machine the snapin is running on.

@TechInADesert turn off secure boot

@michaeloberg Kernel’s have no bearing on PXE booting. You only need to update the kernel in the case your hardware isn’t working with the kernels you currently have. Updating the kernel won’t guarantee the machine will be compatible with fog, however, there’s a more likely chance newer hardware and their relevant drivers will be in newer kernels.

@TechInADesert Then I might suggest you boot the machine in UEFI mode and use the ipxe.efi file as opposed to the ipxe.pxe or undionly.kpxe files.

For the most part, legacy net booting works fine, but there are cases where it just can’t for whatever reason. There’s another possibility causing the issue, in the case the ipxe.efi file doesn’t help anything.

Is your network using STP (Spanning Tree Protocal) and if so, is Fast STP (sometimes called RSTP or PortFast) enabled?