@stormi The new iso worked as usual on a Ubuntu 20.04 VM.
README text formatting looks fine, updating guest tools using the install.sh worked.
When done it still asks the user to reboot the VM though.
Without a working XCP-ng center I'm not sure how to test the guest tools features.

@stormi Exactly. Must've been related to something other than just the latest packages.

@stormi The new iso worked as usual on a Ubuntu 20.04 VM.
README text formatting looks fine, updating guest tools using the install.sh worked.
When done it still asks the user to reboot the VM though.
Without a working XCP-ng center I'm not sure how to test the guest tools features.

I just updated using the ISO-method because the yum method didn't boot successfully.
What would be the best way to migrate from a ZFS file-SR to ZFS-SR? I assume setting the SR type after creation isn't intended and I can't find that in the XAPI docs either.
Is the cleanest solution to create a new ZFS dataset, ZFS-SR on top and move the virtual drives?

@stormi Exactly. Must've been related to something other than just the latest packages.

Finally got some time to test your suggestions.
Removing the microcode_ctl package without dependencies did not help.
Here are both initial ramdisks for anyone interested to look at.

Reinstalling XCP, then ZFS, then updating all packages worked fine.

Thanks @Biggen and @stormi
I'll try updating then removing the microcode_ctl package tomorrow and share the results.

@stormi said in "CROSSTalk" CPU vulnerabilty (cross-core data leak):

Yes, please try:

yum downgrade xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools

Then if it still changes nothing:

yum downgrade microcode_ctl

After all this, you'll be theoretically back to the state from before the update... Though there may be an issue with the initrd generation, which would still not allow you to boot.

Sadly nothing changed after downgrading the packages. The only thing I have changed after the base install was installing your ZFS port.
At this point I would try a fresh install on the weekend and see if the problem reappears unless you have another suggestion.

There is no emergency shell after the failed boot, sadly.

This is what happens after the loading bar on default settings:

Right after selecting "Safe Boot":

Installing the suggested kernel 6.0.10 changed nothing. Should I try downgrading other packages or an even older kernel version?

It is the "Safe Mode" options that results in a kernel panic, not "Serial".
I will grab the screenshots and bugtool logs and test the different kernel later today.

Hi stormi,

I know I am a bit late to report but I just updated my XCP-ng install from the main repo. I'm using an i3-7350K that shouldn't be vulnerable according to Intels list you posted.
After the update default boot settings don't work, the loading screen stalls for a long time then prints a bunch of messages containing "dracut-initqueue timeout - starting timing scripts" followed by "could not boot" and stops there (I don't have the exact wording as I don't have access to the system right now).
If I select safe boot in GRUB there is a kernel panic during boot "couldn't enable IOMMU and iommu=required/forced".
Selecting the 4.19.0 kernel during boot works as usual.

Is there anything else I could try?