Igor

Sadly the problem is a lot more complex Somewhere around PCI bus signaling / initialization / devices comm (tl;dr;)

I just update ZFS today and didn't run into those problems: filename: /lib/modules/6.6.63-current-x86/updates/dkms/zfs.ko version: 2.2.7-0arter97~ubuntu22.04.1 Try to reinstall zfsutils-linux and zfs-dkms. Ubuntu provides 2.2.7, which does not exists upstream ...

Sadly we didn't make Cinnamon images I hope we will manage to come up with this soon https://docs.armbian.com/User-Guide_Armbian-Software/Desktops/ We need to conduct some fixes on the build side to make this work. It already works, but not in a consistent way. When this is achieved, we could keep only one ready-made desktop ... I hope by the next release cycle. If you can't live without Cinnamon, build one. Remember to enable ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu". @prahal will take a look into this.

In tl;dr; format - kernel 6.1.x is private fork, where this SoC support was brought up. A lot of the HW specific code is done quick and dirty, which means in order to move this code to modern kernel, many parts has to be done from scratch. This means devices drivers can be fundamentally different, thus operating different. Sometimes worse or incomplete, usually better. This process is already in motion for about two years now and most of the SoC functions works. We have two Rock5 in production (Github runners for producing images) for about a year now, running modern kernel. I haven't update it for a long time, so its running some weird test version (Linux 6.7.0-rc1-edge-rockchip-rk3588, Up time: 66 days 8:25)

Make a PR and @Tilator will have this auto-fixed via a regular update. Community images are connected to rolling repository - instant fix and ... instant bug

This was a bug in armbian-config ... fixed with https://github.com/armbian/configng/pull/299

You already have best possible desktop on this hardware. Simple and fast XFCE. Changing desktop environment won't make any vivid difference. https://docs.armbian.com/#key-advantages XUbuntu is more or less identical to Armbian Ubuntu with XFCE subtracted for some Canonical proprietary stuff. LXDE vs. XFCE ... not worth the troubles maintaining yet another desktop. Difference is too small. We only keep XFCE, Gnome, Cinnamon and KDE Neon in good shape. The rest waits for enthusiast https://github.com/armbian/build/tree/main/config/desktop and you can always start with a minimal CLI image and build on top any desktop you want.

Cure? There is common misconception that once hardware reaches mainline, that all job is done, while in reality this is where endless problems starts ... and this frustration kills most of attempts to keep this maintained. Doctors, that most scarce resources, not just around Armbian but in general, went to cure other platforms long time ago. We keep Allwinner kernel maintained, but we can't maintain all boards within. Already this is done only by 1-2 people, that don't even have this old hardware at their hands. I have idea to establish a team for retro SBC section, as interest exists, but someone would need to volunteer to assemble and lead such team. (Armbian team is too small for such operations). That would be a viable long term solution to keep older boards in operation. 2c Workarounds - try some of old images and freeze kernel upgrade before upgrading. If the problem is in the kernel - could also be related to something else. https://rsync.armbian.com/oldarchive/cubietruck/archive/

I assume you achieved this performance on cca. 20 x more expensive Intel based hardware? First lets rule out user space. Try Armbian x86 https://www.armbian.com/uefi-x86/ on that. None of this was ever officially supported. And those are 3-4 years builds from 3rd party repository. Armbian makes tools for making custom OS and this was made by "someone" from a vendor kernel that is deprecated in years. I can only give you general advice. - develop image around modern kernel ( config exists but it might not work https://github.com/armbian/build/blob/main/config/boards/sunvell-r69.tvb and https://github.com/armbian/build/blob/main/config/boards/rk322x-box.tvb) - use hardware that is capable of achieving this Good luck.

Official FW is old and re-branded version of Armbian. Without any updates and maintenance for years. Official FW: https://github.com/orangepi-xunlong/orangepi-build/tree/next/scripts Armbian in 2022: https://github.com/armbian/build/tree/v22.08/lib We provide archive for (almost) all previously stabilized images: https://archive.armbian.com/orangepi3-lts/archive/ which are in better shape, but update might break them, so freezing of kernel is required.

Release is not a warranty that all bugs get fixed. That process takes several years and new bugs are keep getting introduced ... proper maitainances keeps this low. Here https://github.com/armbian/linux-rockchip/commits/rk-6.1-rkr4.1/ you can monitor what is getting merged. Rolling update just ships this few hours after merge is made in automatic way.

Please test with both kernels, 6.12.y and stock 6.1.y and then propose changes: https://github.com/armbian/build/blob/main/config/boards/nanopi-r6s.conf#L30-L34

Debian on PC and Debian on SBC is quite different. Userspace, the less relevant part of OS, is coming from there, yes. Ubuntu userspace is, on the other hand, more polished, usually with more updated versions of user space librarires. In tl;dr; its better choice. In the process of OS assembly, we remove Canonical stuff, which means our Ubuntu is more or less the same as Debian, just more polished. Kernel is responsible for most of the troubles people report on this forum / have with those boards. And that has little in common with Debian and Ubuntu. Their kernels mainly don't even boot. And when they do, people would only have significantly more troubles in the area of interacting with hardware - low level instability such as you experience. Then mainline based kernel should be what you are looking after. I have two such machines (Rock 5b), with SSD drives, running GitHub runners. We assemble images on them. They are in production for about a year, running some old test version of mainline kernel (Linux 6.7.0-rc1-edge-rockchip-rk3588) https://paste.armbian.com/fibacokoji

This is the script we ship by default with this hardware. And IIRC it use to work as expected: - spin up at boot is by a purpose, like a check that dan is in operation - when temp goes up, it should spin up It is possible that something isn't working right anymore. Perhaps try to ping author: https://github.com/armbian/build/blob/main/packages/bsp/nanopim4/nanopim4-pwm-fan.sh#L6-L7

Many bugs remain unresolved for years and we, by any means, are unable to have complete bug-fix overview in such a complex world. We can only try to keep some tracking: https://armbian.atlassian.net/jira/software/c/projects/AR/boards/1/backlog https://github.com/armbian/build/issues and resolve when possible.

He supports "everyting", while a team of 50 people, is unable. Who do you think is cheating here? https://docs.armbian.com/#comparison This is how he supports it: He download everything that is valuable from us https://docs.armbian.com/Release_Changelog/#v24111-2024-11-281000 while fixes that somehow finds the way there, they never gets here. Talking about years of work, not this particular fix. We take support serious as we can't steal the bulk of work from someone to mitigate all sorts of troubles related to hard work (burnout, lack of food, etc.), while when you just for fun sale someone else work, this is not a problem. https://docs.armbian.com/User-Guide_Board-Support-Rules/ A small team can only support few boards, the rest is "community supported". By you. Or by nobody. tl;dr; If you add a fix to Armbian, he gets it, we get it. If you sent a fix to him, we don't get it. Image for Odroid C1 is identical to ours with your fix. He doesn't add any fixes to it, besides what you provided. But its "supported" by dietpi Actually all important fixes in this platform was done by us https://github.com/armbian/build/commits/main/patch/kernel/archive/meson-6.1 which means we provide bug fixes even we don't declare hardware as supported. All fixes that gets to Armbian are integrated at once and update is auto generated within few hours, images once per week. https://github.com/armbian/community This is exactly the same support level as other distros, including Dietpi.

Try to rework the script: https://github.com/armbian/build/blob/main/packages/bsp/nanopim4/nanopim4-pwm-fan.sh#L316 Perhaps expand it to support selecting CPU / hard drive ?

If you didn't fix PCI driver, it must have the same isssues. But its good to know / sad to hear, upgrade doesn't fix this. Again you want to beat our recommendations This is (close to) embedded Linux. You have to use, what we tell you to use. Or learn the hard way ... Debian is in worse condition (only on this platform) and there is nothing we can do about. Except removing it. Chromium is broken for few weeks and it will remain broken until Debian fix it ... while Chromium for Armbian Ubuntu is compiled and provided by us. And it works. Workaround is installing previous version, but you will anyway lack video aceeleration. But it won't crash. Remember to include right extensions: ENABLE_EXTENSIONS: "v4l2loopback-dkms,mesa-vpu" or experience will be bad.

There are some troubles, some caused by us, some by 3rd party. Improved mechanism is about to be merged https://github.com/armbian/configng/pull/308

Providing a tool means nothing, What about the most important part, organising and leading? - regularly promoting that we have this and how this operate - establish and maintaining a team of people that will do that. developers don't have time for this and will mainly not cooperate - you need to talk with those people on regular basis - you need to contact them 3 weeks before you need feedback, and a week before to remind them what you are looking for - you need to thank them for helping you - this should not be 1 out of 100 projects you are running, but a project you do in your free time. ... and on and on. This is not technical problem, its organisational one.

There is, but one need to follow forums and GitHub issues to catch everything. If we (which includes everyone) would like to keep download pages updated with this, we will need to do something about. I already do more what is possible. It is complex to assemble and forward right bits of information at right time to right people that needs that information. Bugs are constantly changing information, so we are looking at serious work, nothing what we can finance. Also some bugs are fixed fast and if we already have no resources for fixing bugs, how we could possible have for a complex info system? :) One alternative is official news channel. Currently we have three people working on preparing weekly newsletter. If they didn't catch this on their own, its not published. And last one mention some other problems for example https://www.armbian.com/newsflash/armbian-weekly-highlights-5/ There are many bugs in open source software that are pinned on us and we also produce a lot of code. This one is ours, yes, but its also free software, best effort and what comes with it. WIP https://github.com/armbian/build/pull/7542 More are waiting for good Samaritans: https://github.com/armbian/build/issues Anyone can establish this. I tried that in several ways, but except few people that did testing there was no help in the most problematic part - organizing and leading this operation.

I am afraid this is current state of Rockchip vendor kernel. PCI support works, but its unstable. Just FYI - we needed years to stabilise PCI on previous RK3399 SoC. Situation there was just worse - we were contracted by one of the vendors to do this, so we invested more efforts, but they "forgot to pay" for services even they were backed by contract ... damages to our work helping you is done also by purpose. Workarounds is - cold reboot few times, trying to use some older kernels, where PCI is stable, but there are other problems. Waiting, supporting our work is solution, but that both is hard, when everyone expects software support perfection - that everything just work

Minimum of this is that testing is done at major kernel bumps. We are switching to K6.12 with CURRENT branch, which is main objective and where things will break down for sure. This has to be tested and fixed (if possible) in / by the next release month (2/2025). Them we will stay on that kernel for some time and little will break at 5 and 11 / 2025. We would like to have "supported" boards at least tested. If images are broken, telling that we know that and we know someone is working on it, also works. Perhaps someone else will show up and help around this ... Its more like a grey zone as this is for most of the people a hobby. Yes, better.

Nice to see that you managed to put our build framework into good use! Build configuration can be .conf, if you plan to keep it maintained here, else it can be .csc (community configuration). ! tl;dr; version of support policy can be found here https://docs.armbian.com/User-Guide_Board-Support-Rules/ Code wise, not an issue, all of it, until it met common coding standards (quick check = it does) and that it doesn't break anything else (which I also believe it won't). Remaining problem is the instructions part ... We currently don't have any, not right, not wrong place in the documentation to keep that kind of things well organised. A comment with URL in board config file can do for now. Most of contributions to Armbian are done in similar way.

Also try some older builds. We have one of this board in the automated test system and it works fine. https://armbian.atomonetworks.com/archive/bananapim2ultra/archive/