Igor

This should happen automatically, but takes a day. https://github.com/armbian/os/blob/main/external/zfs-jammy.conf#L9 B -> beta repo S -> stable repo

Confirmed, many thanks for reporting. 6.12.y has troubles with one of the NICs, but as regressions at major kernel upgrades are totally normal and expected in embedded Linux, we are providing you this: https://docs.armbian.com/User-Guide_Armbian-Config/System/#install-alternative-kernels Use older kernels: Make sure you update armbian-config package before doing that, then proceed with "Disable Armbian upgrades" https://docs.armbian.com/User-Guide_Armbian-Config/System/#enable-armbian-firmware-upgrades It was moved to armbian-config -> system -> updates Verify in CLI: igorp@rockpi-e:~$ sudo apt-mark showhold linux-dtb-current-rockchip64 linux-image-current-rockchip64

Its probably a "feature" of new kernel version that broke some mechanism. Kernel 6.12.y is packed well so its something in the middle, corner case. I also don't know more then you.

This is expected and totally normal behavior we are seeing constantly. Without maintenance, support breaks apart. This is just the way it is. You can believe or understand. All the time. And we can't afford to invest more if we already generate huge loss. Not a single vendor ever helped around old devices. While we don't have the millions needed for keeping devices in perfect state, we still invest hundreds of thousands each year to keep these devices running on at 'best effort' basis. Understandably, end users often - always expect military-grade software quality, even though they contribute nothing financially and refer back to hardware dealers for support. Their support is cosmetic, some even fake that support (there are few companies stealing from us, while bragging how they invested into open source). It is their word against ours and it seems users believe dealers, which are always sweet and nice, more ... Loss of the time is always a lot bigger what people can afford, so many people got broke, suffer mental breakdown when helping you (and HW dealers). Lack of your support / compensation is a fundamental problem. Numbers and name suggests lack of polishing and stability, but you expect that things works perfectly? I don't know how to describe you this in tl;dr; - this doesn't work this way. We have Linux kernel, general stuff, which is maintained by general Linux community. Then there is this device family, this device itself (here sadly even several badly compatible revisions). If nobody is dealing with it in general Linux community, which is usually the case, it often breaks at this level before anyone at Armbian even touches it. Then we apply family patch-set on top of this source. Patches often needs adjustments, but luckily they are usually trivial. Still, this takes time. A lot of. We usually don't fix devices at EDGE kernels. This mainly happens when its time to switch kernel at CURRENT (stable / LTS) branch. In 25.2 we switched from 6.6 -> 6.12. For that, our focus for half a year (!) were to 6.12 which was EDGE at that time. Stabilization of mainline kernel with functional addon is our major loss of time. And when it gets down to devices specifics, we are just more limited - we can't test all devices (+ all revisions = impossible) and we can't fix all of them. Recording a bug / known issue is already a luxury. And there is 99% our private time that is lost. Most of end users demands feels very insulting as you have no idea who pays the bills. You don't as also most of vendors don't want to hear about those troubles. Since you don't support developers, people who you think to support you but they don't support you, support at least people which job is to listen to you and collect info for developers. From the loss those people generate, they can't support them better. But you can.

We developed so called Cloud images, which are a combination of minimal images + kernel with minimal set of drivers. Images also doesn't have any firmware packages, so bare OS comes down to 700Mb. Build from sources: ./compile.sh \ BETA=no \ BOARD=uefi-x86 \ BRANCH=cloud \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ ENABLE_EXTENSIONS=image-output-qcow2 \ IMAGE_VERSION=25.2.3 \ RELEASE=noble \ VENDOR="Company" \ VENDORCOLOR="5;100;115" \ KERNEL_CONFIGURE=no \ KERNEL_BTF=yes Customization: https://docs.armbian.com/Developer-Guide_Overview/ Details in promo style: Images were developed and tested in Qemu / KVM, but they should work (well) on all cloud platform. I need some help for testing those images, on any cloud that you can. It should also boot bare metal, but kernel is stripped down and many things won't work. Kernel configs: https://github.com/armbian/build/blob/main/config/kernel/linux-uefi-arm64-cloud.config https://github.com/armbian/build/blob/main/config/kernel/linux-uefi-x86-cloud.config x86 images: https://netcup-01.armbian.com/dl/uefi-x86/archive/Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.20_minimal.img.qcow2 https://netcup-01.armbian.com/dl/uefi-x86/archive/Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.21_minimal.hyperv.zip (Azure format) arm64 images: https://netcup-01.armbian.com/dl/uefi-arm64/archive/Armbian_25.2.3_Uefi-arm64_bookworm_cloud_6.12.20_minimal.img.qcow2 https://netcup-01.armbian.com/dl/uefi-arm64/archive/Armbian_25.2.3_Uefi-arm64_bookworm_cloud_6.12.21_minimal.hyperv.zip (Azure format) We are soon switching to those image for our armbian-config software install testing, so those images will be kept in good shape, but for Cloud deployments we need your help. In case you find them working well out of the box, install Docker "Hello world" and do some general things, please report which Cloud provider this was. Thank you!

Always use main branch, older branches are here for reference and to build with sources at the state of initial build. We had several bug fix builds after point release, but they were made from main branch ... as we don't backport commits to frozen branch. Not enough people ... OS version is not determined by build framework, but externally. https://github.com/armbian/os/blob/main/stable.json Which version is bumped when any new Armbian package is sent to the repository. You can also set version with a parameter IMAGE_VERSION=25.2.3 ... In theory, if we would have "endless" computing / storage resources, we could make RT kernels for all variants. Currently, this is a bit insane as there are too many kernels.

Correct, but I also haven't tried it yet. https://docs.armbian.com/Developer-Guide_Build-Preparation/ Once you get it running, choose this: and enable what needs to be enabled (there must be guides around the internet and AI also usually knows). Make sure to freeze this custom kernel, so update won't be replacing it later.

This board uses modern kernel, where many features are missing: https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Since sources are not coming from Hardkernel, this is what is needed: - developing and adding missing driver - adjusting device tree for this kernel / driver - keeping this working (maintenance) None of this is quick, cheap, easy or simple. If project donations increase by a factor of 100+ or if Hardkernel / someone covers it, we can take meaningful action. Otherwise, progress will depend on random contributions from individual supporters - "Community support".

FYI. I tested booting Rock64 with latest images, but there are several revisions of this hardware and not all might work (well).

Yes. Then we have automatic test install on target release while making a PR. If that passes, merge is good to go.

Yes, it does. But AFAIK only for selecting a correct board: https://docs.armbian.com/User-Guide_Armbian-Config/System/#select-odroid-board-configuration If you know what you are doing, no problem. That's why. And yes, you need to edit boot.ini. We had an idea to remove this Hardkernel proprietary configuration, but never managed to moved to modern boot loader. This HW is 10 years old, if someone wants to change this, else it will stay in this (a bit confusing) state. But it should work. Bigger problem is dying armhf architecture and complex suites such as OMV, might not be build-able anymore and there is nothing we can do about. Alternatively, one can use general tools like Samba / NFS for storage.

Via web: https://packages.ubuntu.com/ by checking dependencies https://packages.ubuntu.com/jammy-updates/zfsutils-linux and figuring out what is the next numbers. As its not always n+1 Askig AI: https://chatgpt.com/share/67e04381-7ecc-8005-b3c3-ade19c10e450

Yes. If you stay with Jammy, you are on old stable user-space, updated directly from Ubuntu, kernels from us. Packages on (old) stable base are rarely updated, usually only if some security problem is detected. If you want to have all packages updating, you need to use Plucky nightly build for your board - accessible at the bottom of download pages. There much more packages will be receiving updates, daily, but that also means bigger risk for running into troubles.

But you can step up and maintain this for everyone? We don't provide direct contact email, as we don't have capacity to deal with all packages that exists in open source world and as you discovered by yourself, some maintainers are not longer with us, so many packages doesn't really have anyone doing this. In our system - all you need to do is changing / bumping numbers and open PR. If build and test succeeds, someone with merge rights, merge it into the system and within few hours, packages are available on repository. PR: https://github.com/armbian/os/pull/300 Pool and test install was successful: https://github.com/armbian/os/actions/runs/14016836904/job/39243546741 Merge follows, packages will be out with next repo sync.

We had to gave up with maintaining this hardware so there is absolutely no warranty that it builds and boots. To verify if your build environment is operational, try to build some supported targets by using a switch ARTIFACT_IGNORE_CACHE=yes This will force recompilation and will tell you if everything is alright. Try with Raspberry Pi or any other supported target to see if things are right at your side.

By community is already supported for some time we even discussed option for official support in cooperation with its maker. We do that for their CB1. Which is Allwinner based, thus pretty different. As @Werner proposed, build is best, also there you can enable HA extension and build with preinstalled Home Assistant. We don't make stable pre-build images, but nighties are generating https://github.com/armbian/os/releases/

If its not in https://archive.armbian.com/, then we don't have it anymore.

If you are using kernel 6.12.y, perhaps related: https://www.armbian.com/newsflash/armbian-weekly-highlights-11/ -> https://github.com/armbian/build/commit/bf9ffa6eedd5df804e3f9a86c84e00607289cd59 which means fix just landed nightly builds.

https://docs.armbian.com/User-Guide_Armbian-Config/System/#install-alternative-kernels

Best recommendation is to drop vendor kernel and start using mainline derived (6.12.y at this point). Can be switched to (CURRENT) in armbian-config. Features that are missing are not much relevant for server setup. We are using RK3588 with mainline kernel in build farm for about a year (even with some development kernel). There ZFS will work without issues / the same as on x86 mainstream Linux distro. This kernel comes from https://github.com/armbian/linux-rockchip and might be very different then kernel.org

- reducing DRAM speed (u-boot) - reading this to get some ideas https://github.com/crust-firmware/crust (it was implemented into Armbian some time ago https://github.com/armbian/build/pulls?q=is%3Apr+crust+is%3Aclosed)

We are having an alias - probably bad move, removing: https://github.com/armbian/build/pull/7962

Single board computers are purpose oriented devices, where booting and using live OS is common. This is how installer was designed - you can boot and run OS from SD card. And move OS to internal memory at any moment - freshly & clean, after one year, never.

Please buy hardware we recommend. Thank you.

Its an old hardware and most popular board with this SoC was Orangepi Zero with which they share most of the problems. I think the only (small) difference related to the temperature is due to physical size and voltage regulation, which can be done differently as its an SoC outside component.