EFI Stub Errors on XCP-ng Virtual Machine Attempting 'Perform Full Host Registration and Inventory'
-
@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.
-
@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.
-
@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?
-
@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.
-
@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)
-
@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.
-
@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.xzMove 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.xzRed Had based server:
sudo chown fogproject:apache /var/www/fog/service/ipxe/init.xzDebian based server:
sudo chown fogproject:www-data /var/www/fog/service/ipxe/init.xz -
@rodluz I tried a manual installation of the updated init.xz as outlined in your instructions, and there was no change. I also upgraded my FOG server and reinstalled your experimental XCP bzImage from earlier in this thread but did not see any change in VM behavior after doing so.
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.
-
Turning off Viridian in the VM settings solves this for me.
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.
-
@pillbox1234567 Thanks for the suggestion. I turned Viridian off on the cloned VM, and it did not make a difference.
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.
