Interesting note that you’ve seen it cause boot issues on certain Linux VMs. I have not experienced that behavior yet but will keep an eye out for it.

Viridian is used to pass details about the machine to the host OS. My understanding is that this is for Windows and I’ve seen it cause Linux VMs to hang on boot. Since this is related to hardware, it’s possible that having the setting on is benign in some cases but not in others.

Out of curiosity, @BPSTravis, what hardware are you running XCP-ng on? I know it’s virtualized, but maybe there’s some CPU feature I have disabled in BIOS on my XCP hosts or something like that?

Also, thanks for your patience. I’m only available to work on this once or twice in the middle of the week as I’m part-time with this organization.

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

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)

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

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?

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.

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.

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?

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

Unfortunately it didn’t work for me. I got stuck at the same point. Screenshot attached. I also tried adding the host kernel arguments back with the experimental kernel and that didn’t change it either. Anything else I should try?

On your FOG server, run this command to download the test kernel
wget https://github.com/rluzuriaga/fos/releases/download/EXPERIMENTAL_XCP_1/bzImage
That will download it to whatever directory you are currently on.

Rename the file and move it to the correct location like this:
sudo mv bzImage /var/www/fog/service/ipxe/bzImage_XCP

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

Red Had based server: sudo chown fogproject:apache /var/www/fog/service/ipxe/bzImage_XCP

Debian based server: sudo chown fogproject:www-data /var/www/fog/service/ipxe/bzImage_XCP

Then add bzImage_XCP to the Host Kernel line in the XCP-ng host on the FOG web.
Also, remove all the host kernel arguments.

I manually added the host and tried the host kernel arguments you suggested. This did not make a difference. I also tried with just xen_emul_umplug=unmodified and this did not work either.

I switched to the Intel NIC option, this did not make a difference.

UEFI BIOS mode was set already.

Try adding this to your host kernel arguments: xen_emul_unplug=unmodified nomodeset vga=788

Also use the intel nic option not realtek. I am not using a custom kernel for my VM, just the latest same as any other machine.

UEFI bios mode on the VM(required for TPM).