The fix has been merged into the master branch.

I've updated from master and tested the metadata backup by manually triggering it 10 times. I had no errors. This issue seems to be resolved.

Thanks to the XO team for this fix!

@pierrebrunet I built on the fix_undici_timeout branch and manually ran the metadata backup job 10 times and did NOT get an error. I will stay on this build through the weekend, let the scheduled metadata backups run, and report back on Monday.

@olivierlambert Good news. This morning, I built on the fix_undici_paused_parser_crash branch and manually ran the metadata backup job 10 times and did NOT get an error. Previously, running the job manually could result in the body timeout error, so we have progress.

I will stay on this build during this week, let the scheduled metadata backups run, and report back by this Friday.

Secure Boot was not enabled in the VM. I enabled Secure Boot in the VM and was able to install KB5012170 without any problem.

I tested further to see if there were any issues related to enabling then disabling Secure Boot in the VM. I did not experience any problems booting the VM after disabling Secure Boot. There were no problems booting the VM after moving it to a pool where the default UEFI Certificates had not been installed.

For anyone wanting to resolve the KB5012170 update error, here are the steps I took:

• On the pool/host for the VM, install the UEFI Certificates with secureboot-certs install
• Shut down the problem VM
• Enable Secure Boot on the VM. I do this via Xen Orchestra but it can also be done with xe vm-param-set uuid=[uuid of VM] platform:secureboot=true
• Boot the VM
• Apply the KB5012170 update
• Shut down the VM
• Disable Secure Boot on the VM via XO or xe vm-param-set uuid=[uuid of VM] platform:secureboot=false
• Boot the VM

https://xcp-ng.org/docs/guides.html#guest-uefi-secure-boot is a very thorough guide on Secure Boot in XCP-ng.

Thanks for the help @stormi

@poddingue On the fix_undici_timeout branch this weekend, all scheduled metadata backups completed sucesfully.

@poddingue Maybe this log will help @pierrebrunet . I've been having the Body Timeout Error for a couple of weeks on Metadata/Config backups. I'm using XO from sources. The problem started after upgrading to commit 63f8d. I was previously at commit e6443. The errors will occur for one or more hosts, and which host(s) has the error seems to be random. The error will occur for hosts which have VMs and for hosts that have no VMs. Attached is this morning's xensource.log from 00:10 when the backup started. The backup ends at 00:15 but I've included log data through 00:20. xensource-truncated.log.txt

I have reverted to a snapshot of XO running at commit e6443 and executed multiple Metadata/Config backups without any problem.

I believe I have the definitive cause for this 'random host reboot' issue.

After 6 months of problem-free operation, I have experienced the host reboot issue again on this server. The host was running only Linux VMs, so the theory of Windows VMs on the host contributing to the reboot issue has proven false. As with each time before, there are no indications in any relevant log files that the host is going to reboot. I think at this point I can definitively say that the reboot is caused by a faulty SuperMicro motherboard.

I've learned my lesson: use HPE servers! This SuperMicro system will be melted down for scrap.

Since I last posted on this topic, I've found that the random reboots only occur when there are Windows Server VMs on the host (Tested with 2019 and 2022). The issue will not occur when running Linux VMs.

My issue seems very similar to the problem described (and solved) in https://xcp-ng.org/forum/topic/6683/windows-server-2019-sporadic-reboot/7

The difference is that in my case, the host restarted and in the other post, the poster reports that the VMs are restarting. Since the poster also tested RAM and found no problems but was able to solve the issue by replacing a suspected DIMM, that information may be useful in the host reboot scenario that I experience.

FYI, I have not replaced the RAM yet and may not actually do it since the server in question is aging and will likely be replaced (with HP hardware) soon.

I've not been able to find information on the signature used by the UEFI bootloader and if that is on the DBX update in KB5012170. Since my original post, Microsoft has updated the Known Issues documentation for KB5012170 and it seems that this problem is now 'known' and has a proposed resolution of, "We are presently investigating and will provide an update in an upcoming release."

So at this point, it appears Microsoft is investigating this as an issue Microsoft needs to resolve, not an issue with the bootloader itself.

Reference: https://support.microsoft.com/en-us/topic/kb5012170-security-update-for-secure-boot-dbx-august-9-2022-72ff5eed-25b4-47c7-be28-c42bd211bb15
(see the third issue listed in Known Issues, which didn't exist until after my initial post)