<div dir="ltr">...And we have a bit of new development in this area -- thanks to contributions collected on <a href="https://opencollective.com/networkupstools/">https://opencollective.com/networkupstools/</a> in the recent past, a new SBC was 
acquired to increase the diversity of the NUT CI farm: an Orange Pi RV2 
with RISC-V (Ky X1) CPU and 8GB RAM for ample build scratch area. So now we can confidently cover yet another CPU architecture, at least for the sake of it.<div><br>I fitted it with an 
additional NVMe, and first fired up 

the OrangePi Ubuntu image, with 
manually added ZFS, but later migrated to their Debian image (to try and
 install Proxmox) in another rootfs which went as easy as populating 
that dataset, changing a line in `/boot/orangepiEnv.txt` and rebooting. I am 
positively impressed about how well integrated recent distros are with 
the tech I like (not that the ride wasn't without its bumps and didn't take a couple of days of experiments to figure out the puzzle) :)<br><br>Despite 8 cores and NVMe, the SBC is 
moderately powerful (as expected from reviews), taking about 15 minutes to configure, build and 
self-test NUT (without PDF docs) from scratch without caches. A 
well-cached re-run of that, however, is down to 6 minutes.</div><div><br></div><div>Connection-wise, this SBC seems to be better equipped than a typical Raspberry, with a couple of GbE ports, and WiFi, and BT, and two(!) NVMe-capable M.2 slots as well as MicroSD/TF and eMMC (and SPI flash seen as MTD block devices for u-Boot code and configuration), audio and RTC, although the GPIO array is shorter (26 pins not 40). The SBC does not have any cooling surfaces nor fans, and does not seem to require any (or have an easy way to fit some); still there is quite a bit of internet lore about retro-fitting Raspberry Pi coolers with straps, etc. Gonna get an adhesive radiator for the CPU chip, maybe memory (that would block a second M.2 port which is not now used) to err on the safe side.</div><div><br></div><div>There are supposed to be UART debug pins, but I did not manage to make use of them when troubleshooting my boot woes. Maybe the system and/or u-Boot were looking out on GPIO UART pins instead, where my scrap-wire loops did not fit safely.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div>

<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 23, 2026 at 5:19 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello all,</div><div><br></div><div>  We have several VMs in the diverse NUT CI farm hosted by DigitalOcean, and they have renewed our yearly grant to run them. Sharing the news partly because of obligation, and mostly out of gratitude :)<br><br></div><div>  In other news, a colleague donated a NAS server they no longer need with significant RAM (so builds may not hit persistent storage) and 8 AMD cores, which (if all goes according to plan) should allow to clear some bottlenecks by adding native bare-metal/containerized builders for platforms that are not so fast in VMs and might fare better this way. If not, it would be another Proxmox node (and a backup storage target on disks that are still there).</div><div><br></div><div>Jim Klimov</div><div><br></div></div>
</blockquote></div>