EFI Stub Errors on XCP-ng Virtual Machine Attempting 'Perform Full Host Registration and Inventory'

[Tom Elliott]

@JCS-RVK Would you be willing to disable your TPM on the XCP-ng device and see if that helps?

[JCS-RVK]

@Tom-Elliott As I couldn’t find a way to disable the TPM without deleting it, I cloned the VM just in case removing the TPM screwed up my Windows install, and added the clone to FOG with the same settings as the original (rodluz’s experimental kernel, same image associated, no kernel arguments, etc).

The cloned VM still hangs at EFI stub: Measured initrd data into PCR 9.

[Tom Elliott]

@JCS-RVK said in EFI Stub Errors on XCP-ng Virtual Machine Attempting 'Perform Full Host Registration and Inventory':

EFI stub: Measured initrd data into PCR 9.

Do you have nomodeset as a kernel argument set somewhere?

Maybe on the Host kernel args or Global Kernel Args?

[Tom Elliott]

@JCS-RVK https://www.reddit.com/r/Ubuntu/comments/1jc7bzj/install_hangs_after_efi_stub_measured_initrd_data/

I’m using this link, I know it’s a thirdparty link but wanted to show my thoughts here.

Based on what I’m seeing -> it would seem to me that the output is working just fine, but sending to a different Video output port than the expected one when the machine boots.

Since it’s waiting on input, the machine appears to be “Hung” but it’s not really, so maybe (without making any other changes) If you’re able connect a monitor (or maybe multiple monitors) to all the Video ports on the machine and see which one is directing video to.

yes, I know this can be clumsy becuase one video card might have multiple output ports.

I hate this issue because it never seems to have a solution, but maybe that’s because there (technically speaking) wasn’t anything wrong. The kernel has decided to send the output somewhere else.

[JCS-RVK]

@Tom-Elliott Just checked, no kernel args set at either host or global levels.

As for your theory about video output going somewhere else, I’m struggling to think of a way to test it as this instance is a virtual machine with no physical display outputs. I did toggle off the VGA setting in the VM advanced settings in XCP, which didn’t make a difference. Once the VM reached the point where it hangs (or appears to), I switched that setting back on, and off, and back on, hoping for a change but nothing happened.

I’ve got the VM set in a capture task now that I’ve manually registered it, and the task never fires according to my FOG web GUI, which makes me think the VM is actually hanging instead of just redirecting display output somewhere else. I tried forcing the task to start, and nothing changed.

[Tom Elliott]

@JCS-RVK Roger thank you.

I know @BPSTravis was able to test with XCP and this particular kernel, so if you’d be willing to maybe share the VM Configuration less any ‘secret’ data?

[JCS-RVK]

@Tom-Elliott @BPSTravis Not much to hide, see attached screenshots as I couldn’t find a way to export the config as an XML. I removed the MAC address from the network screenshot, and note the disk shows disconnected because the VM was shutdown while taking screenshots. Disk resides on an NFS share alongside my other VMs.

The only difference between this VM and the clone I made was removing the VTPM on the clone.

[Tom Elliott]

@JCS-RVK Based on the limited information I see:

VGA RAM on yours is 8MiB vs 16MiB (doubt this would be the issue):

Of other note is the “Secure boot -> Propogate Certificates” which seems to be missing on yours?

Also His VM has 8 cpu limits and memory is much higher (4/16 vs 4/4 on yours):

I’m not saying these are the definitive causes of the problem you’re seeing, rather just pointing out the differences I’m seeing at a glance.

Why one side works, vs the other, I don’t know (using this XCP-ng specific kernel of course)

[JCS-RVK]

@Tom-Elliott I must’ve propagated the pool certificates to the VM already. I looked at my cloned VM and that prompts to propagate certificates. On the clone I matched the settings you called out (Video RAM, CPU, and RAM) and nothing changed.

[rodluz]

@JCS-RVK Okay so I don’t see why this kernel wouldn’t work for you with those settings. Only difference I can think of may be the initrd version that is being loaded. I know that @BPSTravis is using the latest released version so it wouldn’t hurt to update yours too.

I also see that you are running an older version of FOG. You could upgrade to the latest stable release and that will also download the latest initrd.

You could also download it manually if you don’t want to update FOG:

On your FOG server, run this command to download the latest initrd
wget https://github.com/FOGProject/fos/releases/download/20260306/init.xz

Move it to the correct location like this:
sudo mv init.xz /var/www/fog/service/ipxe/

Then you need to change the permissions and ownership of that file:
sudo chmod 644 /var/www/fog/service/ipxe/init.xz

Red Had based server: sudo chown fogproject:apache /var/www/fog/service/ipxe/init.xz

Debian based server: sudo chown fogproject:www-data /var/www/fog/service/ipxe/init.xz