Igor

Of course, once someone donates time to complete this https://github.com/armbian/build/issues/7656

Thank you, appreciated! It is based on Armbian kernel (usually binary) which is a big difference. All our kernels are patched and most of kernels are based on mainline. Some are patched heavily, some less. Stabilization of kernel stack is the biggest expense we have. Credits for our work are everything in this line of work and when someone takes them, it can't be worse. Explaining and fighting for our intellectual property is yet another stupid (common) loss. Mainline kernel is pretty raw which is causing constant troubles, which "based on Armbian, while telling everyone that they are based on Debian and mainline kernel" never have so they can focus on sales (of our work). I understand. This was not directed to you. "talk is cheap" while keeping things operation is something entirely different. Like I mentioned, software support is constant struggle and there is no way to address problems in real time, when people show up on this forum with it (and via emails that are constantly hitting our mall boxes). There are way too many of them and there is very very little support from general public, and there are people that, could help but changing wallpapers and taking credits is more profitable. Going for bleeding edge kernel is not a good solution as it always bring other problems - other features - we don't know - are certainly broken. What we generally do is - completing features on latest LTS kernel, which is 6.12.y, but to which we just switched few weeks ago and is expected to be stable-ish in about 4-6 months. Best kernel, in general, not just for this hardware, is (Armbian, mainline based) is still 6.6.y. Another way - If you seek for quick solution - we keep all older images in the archive: https://rsync.armbian.com/archive/ https://rsync.armbian.com/oldarchive/ Running older (kernel) builds is not what you / we would want, but there are no better options. Constantly changing mainline support is fragile and it will take months to nail things down. If you can help, welcome!

We mainly use Ubuntu Jammy / noble, native or virtualized. All those variants are automatically tested all the time, unlike Windows WSL. I don't know what it the status, but people reported some problems recently. VirtualBox (or similar) and Ubuntu Jammy / Noble is the safest way. Team behind is not professional, so I can't say when this will be fixed. But we are working on.

We have archives of old images https://archive.armbian.com/odroidc2/archive https://rsync.armbian.com/oldarchive/odroidc2/archive/ , but we don't have information which image is good in this function. This is on you to find out.

Those are community supported images - they work or not. Nobody will debug them but you. Just type: armbian-config and switch to alternative kernels which might work better - easy. I accidentally bump into this by scanning copycat projects. Without supplying logs, nobody will answer. This is open source project that invest into R/D. Time is not at our side. There are too many problems in open source, so you need to fight for attention ... and community supported is down to community, make friends first, ask questions next. Team is not covering those. I don't know if you noticed, but he only does lots of chatting and not resolving common problems. https://docs.armbian.com/#comparison FYI (downstream = dietpi) We (developers) know that very well, its quite a norm. Pure luck keep those boards functional - "Armbian community support" counts only on that. Mainline support means little in this regard. Without constant maintenance, things will certainly break apart. This is law in this world. In most cases (supported branches) we fix this before anyone notices. For not maintained, as in this case, - we don't know and don't want to know. I mean, perhaps you got lucky and someone will respond. I think it is better asking CHATGPT. ... which is our work. We suffered and lost months, while he is selling this under his brand while he never helped in any way. Contrary. It is hard to describe how muck work was needed to get this working: (sales person you have been talking too, never worked with / for us) https://docs.armbian.com/Release_Changelog/#v24111-2024-11-28 Here you can make a donation: https://www.armbian.com/donate/ And here you can step up as a maintainer. I would not ask you this, if we would have other options. Then you can sort out and provide people images that works.

Those problems have nothing in common with Ubuntu or its kernel version. Ubuntu does not support any of those boards and if they boot, this is some random luck. In Armbian world, upstream distributions makes no diff as kernel is always ours, Armbian, and the same on Debian and Ubuntu assemblies. We provide different kernels, CURRENT, EDGE, sometimes also LEGACY and VENDOR. CURRENT is primary choice, and is still v6.6.y for all targets. 32bit Neo has obviously different kernel then 64bit Neo, but same version. Then there are things below kernel that cause troubles and are usually per board. The complexity behind can be quite extreme and expensive for time - while wasting time for you, you should pay our bills. This is not the case, so we are forced to drop maintenance at some point as alternative is significantly worse and almost fatal - burning out / bankruptcy. I am sure there are previous images https://archive.armbian.com/nanopineocore2/archive that works good enough / to some degree. On main download pages, we provide rolling releases, which are assembled and untested. If nobody (usually) upstream broke anything, it works, else it doesn't. Knowing that is expensive. We can't afford to pay for that information. We don't know.

nmap 10.0.40.0/24 throws out all devices in this subnet.

32 bit Debian / OMV packages could be a problem. Can you try the same using some other hw platform?

Rationality? 😄 There is no love and there are no humans without irrationality. Yeah, its stupid, but its also fun, just not all the time and not always. Actually R&D is mainly deep and intense suffering with part of great joy. Oh, that is Allwinner stock that nobody ever touched after it was released to public ... There hardware features usually works, but everything else is highly questionable. That images looks to be made by Orangepi fork of Armbian tools. If they would cooperate and contribute to our tool, then it would be much easier ... We tried to raise funds in few occasions. It works to some degree, but costs of organizing this are usually higher then outcome. Organizer of this event must come as volunteer that would help us funding a person(s) that would help everyone ... Sounds complicated, but project needs many other profiles, not just people that knows how to code.

We didn't do nothing. If you leave support to random community, it falls apart. This is the case with all hardware. Armbian community is not Armbian anymore, perhaps we will start to release that under different name to make even bigger distance. We keep archives for this reason. One can always use an old image (similar to "official" image) as it is impossible to provide images in perfect state in moving kernel, not even for one device, for 100 USD per month. (Rpi foundation has around 2M usd budget per year FYI, to get an idea how big loss we make by supporting your wrong purchase), And this is open source - competitors largely does not contribute, and often harm our developers. Orangepi also does not help in positive way and are also not interesting that your hardware works well as you won't buy a new device ... Which is how they make money. tl;dr; There is very very little help and we do what we can.

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.