Igor

I just re-installed Armbian on my x86 server. It works perfectly! We had to drop most of Orangepi hardware due to extreme costs and absolute absence of means to cover them. Anyway most of people are convinced that we are not doing anything (Armbian is just a Debian fork) and that when some hardware reaches mainline, Armbian is pointless, while we lost thousands of hours for each release. Not that we would not like to help you, we are unable to help you. Applying a pressure and asking overloaded and over-stressed developers is very wrong path to get this done. Just do R&D and open a PR and make it perfect state so it won't make us more damages. Even you are willing to dedicated your time, you need a team to support you. And that we cannot provide to you. Our team, barely manage to maintain the basics on this platform and there is nothing we can do about. Nobody cares until it starts to break apart, when its too late and beyond repair. Review is hard work and we are asking for help - you totally ignore it, while you expect significantly more and all the time. Since you know something about this, I am aware you are capable to review everything that comes in and after half a year we will help you around your mission around "HWA working on your computer". We don't need that, you do. What has Debian to do with Panfrost?

Link removed. That's all i can do for the time being. @darkside40 Thanks!

End users already have a huge depth toward developers. Every 3 months we make a summary what was accomplished https://docs.armbian.com/Release_Changelog/#v24111-2024-11-28 (example). And your demands / expectations never stops ... Think again. You / users "only" want that everything work, ignoring / not understanding the path to get there. And what is needed to keep things there - operational. Few ideas for thinking - regressions of low level functions (world we live in) happens all the time. In some cases boards HW design prevents to get to the satisfaction stability level or the software stack / driver was done sloppy and we don't have needed resources to get it right. When its down to software maintaining, most of people doesn't have luxury of time. We steal that time from our families, which is bad. We can only patch the driver even done terrible wrong. Very little people have the luxury of time and needed experiences to do things properly. That is serious problem and sadly common practice. And at the end of the day, open source developers are often irreplaceable and things collapses. There is new and new hardware out ... One possible example (i don't remember details anymore) of this is Odroid C2, where we keep loosing USB support. Then people are insulting us also to emails all the time - from last week: Within years, nobody managed to stabilize this properly. Sometimes it works, sometimes it doesn't. There are plenty of similar cases you are experiencing across other boards containing other SoCs. In theory, SoC defines how low level serial protocols will work, but board HW and SW is a complex field of engineering with lots of signals going around. And those signals can interfere between each other. This means board integrator, especially if they are differing to far from reference design (which could also be done sloppy sometimes). if they just place things on PCB in a critical way (perfect storm), it becomes too costly or impossible to adopt software in order that function works. When kernel is upgraded, things usually broke down again - and you want most recent kernel all the time for security and other general updates. Sometimes they even forget to wire something or similar HW level mistakes. Like I said, this is possible to happened with T6 v1. There is a second revision of this board - with a reason. Something is wrong with v1 (I don't know exactly what). This problem is in the domain of embedded Linux software developer specialized in communication protocols. If you are not that, help with what you master or be open for long-term learning. That is what I am trying to convey.

I think support was dropped because: - asking from him/us 1000 x more then he/we could deliver, - users complete absence of reality (tl; dr;), - users egoistic perspective as primary objective, - usage off private communication channels - constant fight to get attention they don't deserve to get, 24/7 (from on person that needs to have its own life), - asking amateurs to do in super limited time what pros in months or years can't, - constantly attacking with "small" questions that requires hours or weeks of research in order to answer, months to fix some problem (users expect 1day resolution) - most of damaging-time-wasting clients are powered by Dunning-Kruger, so the loss of our super precious time is ridiculously high, - complete absence of financial support from amateurs, - complete absence of financial support from professional abusers of open source (some HW vendors and their clients are not), - constant pressure, stress and no emotional rewards whatsoever, Even users treated him like shit and act abusive, same as here sometimes, he tried to be polite and professional. I don't known anyone that could endure constant insults very long while paying (!) for the time taking them. Imagine being a party host - how long you will stay professional when people f* with your family and puke around your condo? And how long you will host such parties? This is how this relationship looks like, if we allow your frustration to be in charge. I understand that bugs in software are terrible thing, I also feel bad when this happens to me ... but can't pin bugs to us or requests features if you have no idea what you are asking for. We are minimizing this problem for everyone, to find sane grounds. Welcome! Joshua Ubuntu and Armbian Ubuntu are HW wise identical. He was contributing to the kernel our team maintains and we also supported him financially within our possibilities. Those two distros are different in user space / cosmetic details. We don't try to be Ubuntu, he tried to be Ubuntu. We removed Ubuntu stuff, snap is not preinstalled, there is ... I see value in Ubuntu packages as they tend to be more recent and polished then Debian Stable. Similar user-space philosophy as Linux Mint in PC world. This might give some insights https://docs.armbian.com/#comparison Compare his 6.1 to Armbian 6.1 and you won't see any difference. Mainline, 6.12.y kernel is totally different thing, it has been developing more or less from scratch for more then two years. And is not fully completed AFAIK. Very simple Use kernel 6.1.y If you find the way with 6.12.y, kindly share this information with others. Perhaps someone knows and will tell this. I don't know.

Stability of USB stack is quite a problem and should be responsibility of Rockchip. It can't be ours - they don't support us, you don't support us, other distributions just keep leeching and don't help us - Joshua's Ubuntu like OS, if you are mentioning, was the only example, we shared the burden, but users and some Chinese capitalists greed managed to destroy him For everyone. But there are at least two different hardware revisions of T6. Which means, the problem could manifest on one revision but not on another. Sadly some of such things are beyond repair. (I am speculating, as this is second hand info) While you wait that we resolve other 1000 problems, so we can start working on this one, try to be help out https://forum.armbian.com/staffapplications/ Helping us around general task such us reviewing the code, writing documentation, promoting the project, ... If you are asking us for the most demanding and expensive work, at least help us to "clean around the house" and other generic maintenance work. This way you will some day perhaps understand the severity of what you are asking. Rockchip and board vendor engineers were unable to fix this (or there is a HW design issue and problem can't be resolved).

@TonyMac32

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