Team - Hypervisor & Kernel group | XCP-ng and XO forum

dinhngtu

@flakpyro said in VM start stuck on "Guest has not initialized the display (yet).":

@dinhngtu said in VM start stuck on "Guest has not initialized the display (yet).":

You must run secureboot-certs clear if you're updating from 1.2.0-2.4 or 1.2.0-3.1 and have previously run secureboot-certs install with the above versions installed.

Should we run this before installing the update or after 1.2.0-3.2 has been installed?

You should run that preferably after updating all hosts.

@lukasz_s said in VM start stuck on "Guest has not initialized the display (yet).":

@dinhngtu thanks for advice

i've upgraded varstored and varstored-tools:
rpm -qa | grep varstored
varstored-1.2.0-3.2
varstored-tools-1.2.0-3.2
than i've cleared varstore with secureboot-certs clear
should taht folder contain more files ?
ls /usr/share/varstored/
KEK.uth
PK.auth
db.auth
what about dbx file ?

That file is not shipped with varstored nor needed for now. We're validating the final 1.2.0-3.2 and preparing our guidance for the official update.

dinhngtu

@acebmxer All looks good from the output. There might be some VMs that need fixes for Windows dbx updates to work properly, I'll try to add that in the official version.

dinhngtu

@acebmxer Yes, that'll fix the situation.

Note that we're discussing a different approach for the official update, which will involve using a manual repair tool.

dinhngtu

@flakpyro said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu The output of that command seems to result in the output of "Scanningn every UUID in my pool", most of which do not use SB. Im guessing that normal and i do not have any affected VMs any longer?

Yes, it'll produce an error message in unserialize_variables when there's a problem.

@acebmxer Scanning on 1 host will scan the whole pool at once.

In the output you posted, there's only c81f1f1b-9f95-38ec-f96e-5ce8fea073e6 which needs fixing.

dinhngtu

@acebmxer You can confirm if there are other affected VMs using this command:

xe vm-list --minimal | xargs -d, -Ix sh -c "echo Scanning x 1>&2; varstore-ls x" > /dev/null

If there are still affected VMs, you must fix them on varstored-1.2.0-3.2 by secureboot-certs clear + propagating before downgrading to 2.3 (if you wish).

Note that downgrading to 2.3 with pool certs cleared means you'll need to set up guest Secure Boot again. So I recommend staying on 3.2 if it's possible for you.

dinhngtu

@lukasz_s Thanks. As this is a test update, please take note of any issues especially with new Windows installations.

For reference, here are the prerelease notes:

Both varstored and varstored-tools must be updated together.
After the update, to ensure that the new varstored version is running, VMs must be migrated to an updated host (e.g. using RPU) or rebooted.
You must run secureboot-certs clear if you're updating from 1.2.0-2.4 or 1.2.0-3.1 and have previously run secureboot-certs install with the above versions installed.
If you are unsure, it's recommended to run secureboot-certs clear anyway.
If you have already propagated UEFI certificates to your existing VMs following the varstored 1.2.0-3.1 update, it's recommended to update to 1.2.0-3.2 and propagate UEFI certificates again.

dinhngtu

@Greg_E said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu

I was just getting ready to go update my pool... So is it safe now? And do these certs only affect Secure Boot VMs or UEFI VMs as well?

This problem will affect UEFI VMs. See the announcement above for more details.

In short, if you haven't updated, you should be safe; the offending update has been withdrawn and no longer available from yum update (as long as you're not using the testing branch).

@acebmxer said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu Thank you for that reply.

Just to clarify I have 4 host. 2 host i updated to latest update once they became available to public via pool updates. The other 2 host I had to push the second beta release to get command secureboot-certs install to work. Then I pushed the rest of the update again once they became public.

So far im only seeing 1 vm having the issue on the later 2 host the had the beta updates installed. There that test PC and 1 windows server (Printsrver), xoproxy, and xoce.

Should i run those commands on all 4 host or just the later 2 with the troubled vm?

I haven't tested using different versions of varstored within the same pool.

Y	yannsionneau
O	olkur
A	anthonyper
T	ThierryEscande
T	TeddyAstie
D	dinhngtu
A	andSmv

Team - Hypervisor & Kernel

Posts

Member List