RPU Failure on 8.3: Yum HTTPS 500 Error for xo-lite package (Hung Task)

kagbasi-wgsdac

Hello Folks,

I encountered a failure while attempting a Rolling Pool Update (RPU) on my two-node pool on Wednesday and wanted to report the logs to see if this is a known mirror issue or an orchestration edge case.

Environment:

Hypervisor: XCP-ng 8.3 (Two-node pool)
Management: Xen Orchestra (Community Edition / From Sources | Commit 5af3268 )
Update Method: Rolling Pool Update (RPU) feature via XO

Issue Description:
I initiated the RPU task via XOCE. The process failed during the host update phase. The RPU task in the XO UI appears hung (running since 2026-04-29 00:39), likely because the underlying yum process exited with an error that wasn't gracefully handled by the RPU state monitoring mechanism.

The Error:
The logs show a yum failure due to an HTTPS 500 Internal Server Error specifically when trying to fetch the xo-lite package from the mirrors. I can confirm there were no network outages at the time (since I was working remotely and my VPN connection to the site network dropped).

Relevant Log Snippet:

stderr: 'http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/Packages/xo-lite-0.20.0-1.xcpng8.3.noarch.rpm: [Errno 14] HTTPS Error 500 - Internal Server Error
Trying other mirror.

Error downloading packages:
  xo-lite-0.20.0-1.xcpng8.3.noarch: [Errno 256] No more mirrors to try.'

Full JSON Log:

forum won't allow the full log, so I put it on pastebin.  Here's the link:  https://pastebin.com/raw/ueL86MiL

Notes:

It seems like a transient mirror issue, but I wanted to report it as it left the RPU task in a hung state in the UI for over 24 hours. I intend to clear the task and attempt a manual yum update on the hosts as a workaround, however, I'm going to hold off until the end of day today. Perhaps this will provide a live production environment, should the XCP-ng team wish to leverage it, for testing a fix.

Has anyone else seen 500 errors on the xo-lite package recently, or is there a specific mirror I should check?

As it stands now - 2026-05-01 04:30 - the RPU task is still hung (as shown in screenshot #1) and the first host (VMH01 - the pool master) is still in a disabled state (screenshot #2).

Thanks for all the work on 8.3!

SCREENSHOT #1 - Showing hung RPU task

SCREENSHOT #2 - Showing master host in disabled state

olivierlambert

Pinging @julienxovates for feedback about RPU