maximum hosts in pools are 3, so it is still easy to process manually
thoses with 5-6+ hosts must be more painful

Rolling pool reboot failed me again... This time it got stuck evacuating a host with no VMs.

@acebmxer said:

@rzr
No issues to report initially other then nslookup still an issue.

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace

Yes I looked at it, it looks like it's a design isssue that was fixed in later version of bind.

In details If I understand correctly this patched version of nslookup is facing a SIGARBT caused by an assert on previously cleanup resources (dst__memory_pool) which is unexpected in finishing part of the openssl thread (dst__openssl_destroy).

This bind patched version (where ssl support is in progress) is also known to have memory leaks, but those are resolved in later version, so until we catch up you'll probably have to live with this little annoyance on process exit unless we find (and validate) a better fix.

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 ~]# 

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.3
• intel-microcode: 20260416-1.xcpng8.3 -> 20260416-2.xcpng8.3
• kernel: 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
reboot

The 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.

If so, can you run the following command: xe host-call-plugin host-uuid=<uuid-host2> plugin=updater.py fn=check_update

@marcoi said:

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

@rzr said:

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.

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).