XCP-ng 8.3 updates announcements and testing
-
[09:43 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 -bash: nslookup: command not found[10:21 xcp-ng-haznrrtw ~]# yum install bind-utils -y Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org Resolving Dependencies --> Running transaction check ---> Package bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Processing Dependency: bind-libs = 32:9.9.4-63.1.xcpng8.3 for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libbind9.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libdns.so.100()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisc.so.95()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccc.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccfg.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: liblwres.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Running transaction check ---> Package bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================= Package Arch Version Repository Size ========================================================================================================================================= Installing: bind-utils x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 126 k Installing for dependencies: bind-libs x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 948 k Transaction Summary ========================================================================================================================================= Install 1 Package (+1 Dependent package) Total download size: 1.0 M Installed size: 3.0 M Downloading packages: (1/2): bind-libs-9.9.4-63.1.xcpng8.3.x86_64.rpm | 948 kB 00:00:00 (2/2): bind-utils-9.9.4-63.1.xcpng8.3.x86_64.rpm | 126 kB 00:00:01 ----------------------------------------------------------------------------------------------------------------------------------------- Total 855 kB/s | 1.0 MB 00:00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Installing : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Verifying : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Verifying : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Installed: bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 Dependency Installed: bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 Complete! [10:22 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: vates.com Address: 172.67.205.118 Name: vates.com Address: 104.21.52.238 openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace #0 0x7f419d8790e7 in ?? #1 0x7f419d87903a in ?? #2 0x7f419e486780 in ?? #3 0x7f419cc91df6 in ?? #4 0x7f419ccd8464 in ?? #5 0x7f419ccd8732 in ?? #6 0x7f419ccd7b8d in ?? #7 0x7f419b442bd9 in ?? #8 0x7f419b442c27 in ?? #9 0x7f419b42b44c in ?? #10 0x405818 in ?? Aborted (core dumpedEdit -No further issues to report at this time.
-
Installed on my usual batch of test hosts, no issues so far.
-
Hi,
I installed the update candidates within my test environment.
Updates installed fine, after reboot all looks good so far.
No apparent issues can be seen.
-
Maybe this schould be under XO/Backup
Anyhow.ph7 said:
Ran the 2 updates released today and...
Back to only showing one VM inBackup/Restoreas it did a month or 2 ago.
Ran the replication job and all VMs showed up inBackup/Restoreagain. (XO5)It occurred again today, only showing 1 VM in restore
XOdaefc
Host updated 2 weeks ago.
After 1 scheduled CR job ran all VMs showed up again -
-
In the back of my head I knew there was a thread and I found it
https://xcp-ng.org/forum/topic/12040/restore-only-showing-1-vm/21?_=1780396449511 -
@rzr
It seems to be working
edit: the update that is. -
@rzr Update installed and running on pools. Normal operations seem good. Had some issues with rolling pool reboot, but that happens a lot (unrelated to updates). An updated
bind-utilswould be nice, and any other SSL affected packages. -
We pushed the tested updates to the xcp-ng-updates repository, check blog post for summary and related advisories:
https://xcp-ng.org/blog/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/Thank you again for feedback we will try to address reported issues on next batch (to come soon).
Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).
-
@Andrew We'll publish a fix for
bind-utils, indeed, even if it's not part of the officially supported additional packages for XCP-ng, as it can be useful and we don't have strong reasons not to fix it.Regarding other packages affected by the openssl update, @rzr handled many of them as part of the OpenSSL update back then already, so now we'll mostly rely on reports such as yours in case we missed something which is actually used by the user community.
-
Thank you again for feedback we will try to address reported issues on next batch (to come soon).
Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).
Not knowing myself what it meant, I asked Philippe: it's about the nslookup issue. And potentially the issue reported by @ph7 but it's not clear to me yet if there was a problem with XCP-ng or Xen Orchestra.
Anyway, basically this means that there's no known issue caused by this batch of updates, and that we'll keep addressing any relevant issue in the next updates if necessary, as usual.
-
Applied patches at work. 3 pools updated with zero issues.
-
latest patches, host1 /master patches went well and rebooted. moved vms over.
host 2 in pool click on patch and it just sat there.
i ssh into the host2 yum clean metadata and yum update manually applied updates.
XO still showed host 2 needing patching, so i reboot it. XO still showed host 2 need patches.
I rebooted XO. host 2 shows patch, and task still remains in XO. Any idea how to clear it out from XO. or is it wait 24 hours kinds of thing? -
i ssh into the host2 yum clean metadata and yum update manually applied updates.
Did you try to reboot it just after ?
XO still showed host 2 needing patching, so i reboot it
Seems not.
What about rebooting the host too ?
Let me pass the world to @Team-XO-Backend
-
Hi @rzr,
When you say, "XO still showed host 2 needing patching", does that mean XO is still showing missing patches?If so, can you run the following command:
xe host-call-plugin host-uuid=<uuid-host2> plugin=updater.py fn=check_update -
after i manually applied the patches, i used XO to reboot the host 2.
After the host 2 rebooted, XO still showed the task running and the host2 showed it needed to be patched. I rebooted XO and the task is still there ( been there for 13 hours now lol. ) but now host 2 shows patched -
@marcoi perhaps a restart toolstack would correct the phantom task ?
but at the end of patching of the master a restart toolstack should have happened already, automatically... -
New security update candidates for XCP-ng 8.3 LTS (kernel)
This release batch contains security fix on kernel, version update, some bug fixes and a few improvements.
What changed
Virtualization & System
-
kernel: Fix Vulnerability: CVE-2026-46243- Fixed the CIFSwitch security vulnerability that could allow privilege escalation from a user with low privileges.
-
intel-microcode: Fix a hang on boot on some platforms (Revert Granite Rapids AP/SP ucode back to IPU 2026.1)
Drivers
intel-ice: Update to 2.4.5- Adds support for E825-C and E830.
- Adds support for Link Aggregation (LAG).
- Various stability, performance, and bug-fix updates.
Versions:
intel-ice: 1.15.5-2.xcpng8.3 -> 2.4.5-8.1.1.xcpng8.3intel-microcode: 20260416-1.xcpng8.3 -> 20260416-2.xcpng8.3kernel: 4.19.19-8.0.46.5.xcpng8.3 -> 4.19.19-8.0.46.6.xcpng8.3
Test on XCP-ng 8.3
yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates rebootThe usual update rules apply: pool coordinator first, etc.
What to test
As usual, normal use and anything else you want to test.
Test window before official release of the updates
~3 days
We would like to thank users who reported feedback since our last call for testing:
@Andrew, @acebmxer, @flakpyro, @jeffberntsen, @majorp93, @marcoi, @ph7, @pilow, @probain.
-
-
Installed updates on home lab. No issues to report initially other then nslookup still an issue.
[10:54 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: vates.com Address: 104.21.52.238 Name: vates.com Address: 172.67.205.118 openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace #0 0x7f163cd960e7 in ?? #1 0x7f163cd9603a in ?? #2 0x7f163d9a3780 in ?? #3 0x7f163c1aedf6 in ?? #4 0x7f163c1f5464 in ?? #5 0x7f163c1f5732 in ?? #6 0x7f163c1f4b8d in ?? #7 0x7f163a95fbd9 in ?? #8 0x7f163a95fc27 in ?? #9 0x7f163a94844c in ?? #10 0x405818 in ?? Aborted (core dumped) [12:50 xcp-ng-haznrrtw ~]# -
Installed on my usual hosts, one of which has an E810 and used the ICE driver, no issues so far however i am not using LACP bonding on that host.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login