Igor

Bullseye is problematic, while buster ... please upgrade / drop it !!

There is no need for privacy as logs don't carry any private information. And I didn't ask you to send me anything I advised you how you should present information to this community in order to meet minimum requirements. Who will look into this, I don't know. There is no warranty anyone will - support is "best effort". This is best we can do. Personally I am overloaded with problems for years, so I won't be resolving this problem. Not anytime soon. To have a picture on how much problems are thrown our / my way ... We will hire few people eventually to help us helping you around your endless problems faster. I have no better idea. As you can see, even our paste server is broken and need fixing ...

We need to refactor updating mechanism and that requires few days, a week of work. Remember that our total public project budget is this shared among 1000+ problems. There is nothing we can do to speed up.

Yes, that is best way. First question is - is eMMC device recognized and it seems it is. So it would be handy to see everything, try updating to latest daily builds ... bug in armbian-install script is possible too.

By showing symptoms without logs people can only tell you that "something is wrong" Which you already know.

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.