@Andrew said:

Thank you for this report, I fear this issue appeared when we rebuilt bind with openssl-3

nslookup vates.com 8.8.8.8

I confirm this issue, note that bind-utils is not installed by default, let me investigate.

New security and maintenance update candidates for XCP-ng 8.3 LTS (kernel)

This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements.

What changed

Virtualization & System

• kernel: Update to 4.19.19-8.0.46.5

  • Fixes multiple vulnerabilities:
    • CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit Fragnesia.
    • CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as ptrace_may_dream.
    • CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit pintheft.

• qemu: Fix a potential issue in guest memory mapping lookup.

• edk2:

  • Fix issues while booting from physical CD/DVD drive.
  • Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs)

• dmidecode: Update to 3.6-3

  • Version able to read type 42 tables (redfish)

• varstored: Update to 1.3.2-2.1

  • Sync with upstream.

• ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags

Control plane

• xapi: Enable USB passthrough of smartcards

Storage

• blktap: No functional change. Only sync with upstream.

Network

• openssh: Drop support of insecure clients
  • Old OpenSSH clients (version less than 7.2) can no longer connect with ssh-rsa (due to SHA-1 being no longer accepted by the server).
  • The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use ED25519 keys.

Others

• libtasn1: Update to 4.21.0 (hardening)
• fuse: Rebuild
• slang: Rebuild
• systemtap: Rebuild

Optional packages

• libreswan: Rebuild
• netdata: Rebuild

Versions:

• blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3
• dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3
• edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3
• fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3
• ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3
• kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3
• libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3
• libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3
• openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3
• netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3
• qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3
• slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3
• systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3
• varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3
• xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.2.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

~1 day

We would like to thank users who reported feedback since our last call for testing:

@Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.

@ovicz said:

I get this in dmesg after the latest updates :

[   54.673443] python3[3691]: segfault at 200000 ip 00007f16eb8eca9f sp 00007ffd                                                                                                             b84e9ff0 error 4 in libpython3.6m.so.1.0[7f16eb804000+28d000]
[   54.673450] Code: 01 00 00 8d 5f ff 48 8d 2d de 3a 3c 00 c1 eb 03 44 8d 24 1b                                                                                                              4e 8b 44 e5 00 49 8b 70 10 49 39 f0 74 5f 49 8b 40 08 41 83 00 01 <48> 8b 38 48                                                                                                              85 ff 49 89 78 08 74 0d 48 83 c4 10 5b 5d 41 5c c3 0f
[   84.587661] xapi[3697]: segfault at 7f28cacaea40 ip 00007f28c6df0ec2 sp 00007                                                                                                             f289a5b8af0 error 6 in libjemalloc.so.2[7f28c6d85000+85000]
[   84.587669] Code: 48 2b 73 08 44 8b 4d 84 ba 01 00 00 00 49 83 c2 01 49 0f af                                                                                                              f1 4c 8d 0d ac 72 42 00 48 89 f1 48 c1 ee 26 48 c1 e9 20 48 d3 e2 <48> 31 54 f3                                                                                                              40 48 8b 8d 58 ff ff ff 48 8b 33 48 8d be 00 00 00 10

Hi, if possible can you share us more information to troubleshoot, like a xen-bugtool --yestoall output ?
https://docs.xcp-ng.org/troubleshooting/log-files/

If you can also do the usual hardware check (eg: memtest) that would help, because my intuition is that it is not related to this precise update but we like to be sure.

@ph7 said:

@rzr

XO-lite was already on 0.21.0 (13f98) after the update 2 weeks ago.. Don't know if it's the same.

yes it's same landed in testing before and not yet moved to updates, btw this version does not bring much change as it's a rebuild with dep update, see there is no full changelog :

https://github.com/vatesfr/xen-orchestra/releases/tag/xo-lite-v0.21.0

@JeffBerntsen said:

@rzr

I'm seeing 30 updates as well but they're installed and seem to be working fine on my test systems.

I think I only listed sources packages (which contains several binaries sub-packages having the same versions), so that's expected

BTW thank you for reactivity on testing

New security update candidates for XCP-ng 8.3 LTS (kernel, xen, intel-microcode)

This release batch contains security fix on kernel, version updates, some bug fixes.

What changed

Virtualization & System

• kernel: Update to 4.19.19-8.0.46.3
  • Fixes CVE-2026-43284 (used by the DirtyFrag and CopyFail2 exploits)
• intel-microcode: Update to 20260416-1
  • Improve Intel support and security INTEL-SA-01420
• xen: Update to 4.17.6-8.1
  • Minor bugfixes for x86 systems, including calibration of various timers and handling of PCI devices when disabling SR-IOV

Control plane

• xapi: Update to 26.1.4
  • Minor NUMA fixes

UI

• xo-lite: Update to 0.21.0
  • chore: upgrade dependencies with known security vulnerabilities (#9640)
    • These vulnerabilities are not believed to affect XO Lite itself. They are fixed as defence-in-depth.
  • Changelog

Versions:

• gpumon: 24.1.0-83.2.xcpng8.3 -> 24.1.0-84.1.xcpng8.3
• intel-microcode: 20260115-1.xcpng8.3 -> 20260416-1.xcpng8.3
• kernel: 4.19.19-8.0.46.2.xcpng8.3 -> 4.19.19-8.0.46.3.xcpng8.3
• xapi: 26.1.3-1.10.xcpng8.3 -> 26.1.4-3.1.xcpng8.3
• xcp-featured: 1.1.8-6.xcpng8.3 -> 1.2.1-1.xcpng8.3
• xen: 4.17.6-6.2.xcpng8.3 -> 4.17.6-8.1.xcpng8.3
• xo-lite: 0.20.0-1.xcpng8.3 -> 0.21.0-1.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

~1 day

We would like to thank users who reported feedback since our last call for testing:
@Andrew, @FritzGerald, @IgorGlock, @bufanda, @flakpyro, @manilx, @marcoi, @ovicz, @ph7.

@bnerickson said:

Thanks for the reminder, for some reason it was not seen before (all applogies).

I'm unsure where to report this,

Here or in related open projects directly (assuming you know where to look at) but let me guide you.

but syslog reports the following warning when a VM starts:

(UDEV-WORKER)   cpu0: Process '/bin/sh -c '[ -e /dev/xen/xenbus ] && [ -e /sys/devices/system/cpu/cpu0/online ] && echo 1 > /sys/devices/system/cpu/cpu0/online'' failed with exit code 1.

Good catch, it's a bad habit to use AND (&&) in conditionals.

Hardcore programmers prefer to use OR (||) in scripts, this practice prevents failed exit and make debugging easier (with set -xe).

(...)

> ACTION=="add", SUBSYSTEM=="cpu", RUN+="/bin/sh -c 'if [ -e /dev/xen/xenbus ] && [ -e /sys$devpath/online ]; then echo 1 > /sys$devpath/online; fi'"

That would work, What about this "simpler" form ?

[ ! -e /dev/xen/xenbus ]  || [ ! -e /sys$devpath/online ] || echo 1 > /sys$devpath/online 

Could be harder to read, but I get used to.

If you want you can contribute the fix directly to upstream since the file is public at:

https://github.com/xenserver/xe-guest-utilities/blob/master/mk/xen-vcpu-hotplug.rules

About the exec bit, here is the line that should be changed:

https://github.com/xcp-ng-rpms/xcp-ng-pv-tools/commit/3d134fbd0f3ac9e2f3cfa914e38b33529635d458#r183816712

@bnerickson, If you need any mentoring for OSS contributions, I would be more than a happy to help.
Since it's a lowest priority you can take all the time you need, and If too busy, no problem we can do it for you and then backport the change to XCP-ng.

New update candidates for you to test!

We are continuing to refine the next batch of update with planned fixes. This release batch contains fixes on the major storage feature previously announced, read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

What changed

Storage

QCOW2 image format support is the major feature of this release batch, check related announcement in forum.

Some fixes have been applied to fix issues found during the testing phase.

• sm: 3.2.12-17.6

  • Limit QCOW2 VDI max size to be 16TiB with metadata to allow compatibility with EXTSR (EXTSR is limited to 16TiB unique file size)

    • If a full QCOW2 VDI is allocated, XCP-ng would not be able to migrate it to an EXTSR with this limitation.

    • In the future, while EXTSR will remain limited to this maximum size, other SR types will evolve towards higher limits. For this, we'll have to work on the existing assumption that all SR which support the QCOW2 image-format share the same maximum size limit for VDIs, and to catch migration attempts towards SRs whic cannot receive disks bigger than their maximum limit.

• blktap: 3.55.5-6.6

  • Update the package's license.

Versions:

• blktap: 3.55.5-6.5.xcpng8.3 -> 3.55.5-6.6.xcpng8.3
• sm: 3.2.12-17.5.xcpng8.3 -> 3.2.12-17.6.xcpng8.3

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

And, 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, in less than 24h: @acebmxer, @Andrew, @MajorP93.

Feature fixes, security and maintenance update candidates for you to test!

This release batch contains fixes on the major storage feature previously announced,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with back-porting security patches from the latest version of OpenSSH.

An additional driver fix is part of this minor package set.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

Some fixes have been applied to fix issues found during the testing phase. Many thanks go to @Andrew who found a CBT-related bug on file-based SRs!

• sm: 3.2.12-17.5
  • Fix a regression on CBT (Changed block tracking) on file-based SRs (EXT, NFS, ...), causing backup jobs using the "purge snapshot data when using CBT" option to create full backups each time instead of deltas.
  • Deactivate unused LVM snapshot base before deletion to prevent LVM leak. This fix is not related to the QCOW2 feature, but is important and localized enough for us to provide it in addition the other changes.
  • Minor fix that prevents a warning when updating the package.
• blktap: 3.55.5-6.5
  • Fix install warning when triggering mdadm to generate a udev rule.

Network

• openssh: Update to 9.8p1-1.2.3
  • Two vulnerabilities disclosed along with the OpenSSH 10.3 release have been fixed.
    • In authorized_keys, when principals="" was defined along with a CA with a common CA, an interpretation error occurred, which could lead to unauthorized access.
    • When one ECDSA algorithm was active, it activated all others regardless of their configuration. (By default, all ECDSA algorithms are active.)
  • For more details please track the upcoming Vates Security Advisories.

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• qlogic-fastlinq-alt: 8.74.6.0-1
  • Fixes 2 issues in the qede module driver:
    • Driver does not retain configured MAC and MTU post reset recovery
    • Driver does not recover from TX timeout error

Versions:

• blktap: 3.55.5-6.4.xcpng8.3 -> 3.55.5-6.5.xcpng8.3
• openssh: 9.8p1-1.2.2.xcpng8.3 -> 9.8p1-1.2.3.xcpng8.3
• sm: 3.2.12-17.2.xcpng8.3 -> 3.2.12-17.5.xcpng8.3

Optional packages:

• qlogic-fastlinq-alt: 8.70.12.0-1.xcpng8.3 -> 8.74.6.0-1.xcpng8.3

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:

• SSH connectivity

And, as usual, normal use and anything else you want to test.

Test window before official release of the updates

~4 days

We would like to thank users who reported feedback on the QCOW RC2 release: @acebmxer, @andrew, @bufanda, @flakpyro, @jeffberntsen, @ph7

@cobordism said:

yum update --disablerepo=* --enablerepo=xcp-ng-base,xcp-ng-updates

It's currently in testing and will move to updates if everything (not only nut) is ok:

yum install --disablerepo=* \
   --enablerepo=xcp-ng-base,xcp-ng-updates,xcp-ng-testing  nut

Package landed in testing repo please check the related announcement:

https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/432

Then please confirm the issue is gone by editing post topic with "[SOLVED]" prefix

@Andrew said:

@rzr Installed on test machines with some warnings:

  Updating   : blktap-3.55.5-6.4.xcpng8.3.x86_64                           9/87
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.4.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package blktap-3.55.5-6.4.xcpng8.3. x86_64

Yes this was reported as "Known issues"

On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

  Updating   : sm-fairlock-3.2.12-17.2.xcpng8.3.x86_64                    32/87
Warning: fairlock@devicemapper.service changed on disk. Run 'systemctl daemon-reload' to reload units.

I observed this too, maybe this should be documented too, a reboot will work too.

New feature, security and maintenance update candidates for you to test!

This release batch contains a major storage feature,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with a major OpenSSH update.

The updated Windows Guest Tools bring support for the XSTDVGA driver, allowing display resizing.

We also publish other non-urgent updates which we had in the pipe for the next update release.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

• sm: 3.2.12-17.2
  • Add support for the QCOW2 image format
• blktap: 3.55.5-6.4
  • Add support of new QCOW2 disk type

Maintenance updates

Virtualization & System

• xen: 4.17.6-6.1
  • Sync with XenServer's xen-4.17.6-6.xs8
    * Fix boot failure on some UEFI systems. WIP
• kernel: 4.19.19-8.0.46.1
  • Fix regarding use of the correct MAC address in the rndis_host driver
  • Backport fix regarding a potential bug in the ext4 driver (CVE-2020-14314)
  • Backports fixes in SUNRPC (related to NFS). This prevents host crashes under some circumstances.

Control plane

• xapi: 26.1.3-1.6
  • Several fixes to QCOW2 enablement for importing and exporting, like reducing memory usage on disk import
• xcp-ng-xapi-plugins: 1.16.0-1
  • sdncontroller.py: add support for new optional cookie argument to add-rule and del-rule functions
• xcp-ng-pv-tools: 8.3-16
  • Update to XCP-ng Windows PV Tools 9.1.146.0
  • Include the XSTDVGA driver and improvements to the guest agent/installer

UI

• xo-lite: Update to 0.20.0-1
  • [VM/New] Added secureBoot support (PR #9423)
  • [Dashboard] Fix reactivity of dashboard (PR #9378)
  • [VM] Fixed duplicated ip addresses in the network tab Forum#101359 (PR #9547)
  • [Stats] Return null instead of 0 when no stats available (PR #9634)
  • [Treeview/Pool/Host] Add button to download bugtools (PR #9419)

Network

• gnutls: 3.3.29-10.2
  • Fix dane removal (no more replacing dane with devel package)
• openssh: Update to 9.8p1-1.2.2
  • Deprecate old OpenSSH clients (7.2 and lower) that use weak SHA1 with ssh-rsa:
    • For now, a warning will ask to use an up to date client, on next update weak configurations will be rejected.
• net-snmp: 5.9.3-8.2
  • Fix SNMP regression (daemon configuration was lost in earlier version)
• xcp-ng-deps: 8.3-14
  • Install traceroute to troubleshoot connectivity problems

Additional packages

Best effort support is provided for additional packages provided by the XCP-ng project.

• lldpd: version 1.0.4-1.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng 8.3 updates. However, please prefer the pre-installed lldapd whenever possible.
• nut: version 2.8.0-2.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng updates.
  • User feedback is welcome

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• emulex-lpfc-alt: 14.4.393.31-1.1
  • This is an alternative driver which handles newer Emulex lpfc devices.
• sfc-module-alt: 5.3.18.1012-1
  • Initial alternate driver for Solarflare SFN5XXX|6XXX|7XXX|8XXX|X2, version 5.3.18.1012

Versions:

• blktap: 3.55.5-6.3.xcpng8.3 -> 3.55.5-6.4.xcpng8.3
• gnutls: 3.3.29-10.1.xcpng8.3 -> 3.3.29-10.2.xcpng8.3
• kernel: 4.19.19-8.0.44.1.xcpng8.3 -> 4.19.19-8.0.46.1.xcpng8.3
• net-snmp: 1:5.9.3-8.1.xcpng8.3 -> 1:5.9.3-8.2.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.2.xcpng8.3
• sm: 3.2.12-17.1.xcpng8.3 -> 3.2.12-17.2.xcpng8.3
• traceroute: 3:2.1.5-2.xcpng8.3
• xapi: 26.1.3-1.3.xcpng8.3 -> 26.1.3-1.6.xcpng8.3
• xcp-ng-deps: 8.3-13 -> 8.3-14
• xcp-ng-pv-tools: 8.3-15.xcpng8.3 -> 8.3-16.xcpng8.3
• xcp-ng-xapi-plugins: 1.15.0-1.xcpng8.3 -> 1.16.0-1.xcpng8.3
• xen: 4.17.6-5.2.xcpng8.3 -> 4.17.6-6.1.xcpng8.3
• xo-lite: 0.19.0-1.xcpng8.3 -> 0.20.0-1.xcpng8.3

Optional packages:

• lldpd: 1.0.4-1.1
• nut: 2.8.0-2.1

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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.

Known issues

• On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

What to test

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:
* SSH connectivity
* SNMP, if you use it

And, as usual, normal use and anything else you want to test.

Test window before official release of the updates

~2 weeks

@FritzGerald said:

@rzr Just for curiosity.

As far as I understand you assess the risk as low for the nut package - and only for that - to use ci-repo. I am fine with that for my personal servers.

• Would you consider to integrate this into "stable" branch?

yes it's the plan, we usually test packages in ci repos for a couple of weeks and once we're happy of the packages set it goes to testing repo, then users can officially test it (and based on feedback (or absence of feedback) then everything lands in update repo after a week or more (it depends on risk or hurry)..

• What would be the next steps on our side to support this?

I think nothing should be done your side you did your job before the testing window, early feedback is always appreciated (as long people know what they are doing )

But If I were you, just to be safe i would keep trace of packages i have installed from ci or testing repo, in case anything is not going as expected, you can still reinstall those packages from update channel.

• How long would does that roughly take?

It depends usually a couple of weeks, but this next batch might be a bit longer because there is a long waited feature planned.

Check the future announcement in the forum.

Thank again!

thank you for the detailed howto, if there is traction for this feature maybe it worth documenting officially, I'll ask product managers.

@FritzGerald said:

@rzr: Sorry, first and foremost I totally forgot to say thank you very much. I really appreciate you work and effort for this "non-core" issue.

You're welcome !

Keep in mind using/enabling ci repo can be dangerous but for this nut update the risk is low.

Is there maybe anything particular you are interested in for me to test?

Nothing specific, the regular use case but feel free to share to community your experience with your hardware:

https://networkupstools.org/ddl/APC/Smart-UPS_750.html

Then others can compare with other devices supported by N.U.T. :

https://networkupstools.org/ddl/

This makes me think, I have scavenged an APC BE400 but it looks like an offline device, unsure I will make anything useful soon.

Hi, I had a look at it and may have something to be tested soon (TBC https://github.com/xcp-ng-rpms/nut/pull/1 )

Is any of you volunteering for testing an extra (unsupported?) package ?
Or if the client is enough maybe we can put this on hold unless there is more traction?

Reminder: https://docs.xcp-ng.org/management/additional-packages/

@Kajetan321 said:

It looks like "yum remove nut" does the trick.

Yes this "extra" tool was not (never?) supported ,

If you really need it, there are 2 options to consider:

• 1st is convince us to add it to the distro
• 2d rebuild it yourself (to link with updated dep, and also rebuild its deps like neon)

@Mitchel-APD said:

Just updated 1 pool with 3 hosts.
SNMP did not work anymore, config file was not changed.
Got the following error: Authorization Error (SNMP error # 16)

Thank you for your feedback, we're going to investigate, I see that there are many changes between both versions:

https://github.com/net-snmp/net-snmp/compare/v5.7.2...v5.9.3

@gb.123 said:

Wrong diagnostic page; asked for 1 got 8
Failed to get diagnostic page 0x1
Failed to bind enclosure -19

be there in previous updates and may not be related to this particular update.

I think you're right because the issue you are facing is reported by kernel itself (which was not updated), Can you please share more details about the hardware you're using (is any USB device involved ? try smartmon tools too) eventually post details in other sections of forum.