Igor

Another one: https://www.digitalocean.com/community/tutorials

Stick to this board: https://www.armbian.com/bananapicm4io/ So far we have a person behind and a tiny budget, so our personal finances are not blown in 100%. Behind Orangepi CM4 we have nothing except random community work and with this it is not possible to plan any actions.

No idea. its a part of stock Debian timezone & locales generation. Here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tzdata;dist=unstable https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=locales;dist=unstable

It is. - Armbian works perfectly well on 1st class hardware such as x86, ampere aarch64, raspberry pi, ... - Armbian also works well on our test devices https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results - Armbian boots normally on 16Gb Orangepi Plus 5 https://paste.armbian.com/quzavajida (Armbian_23.11.1_Orangepi5-plus_bookworm_legacy_5.10.160.img.xz) It is certainly a hardware issue without even looking into the logs. What is then? Vendors often change memory chips (sometimes without telling anyone) so only their images works with a new batch of boards until we waste insane amount of time to figure that and fix = huge blow for our personal time / finances ... A change of memory chips is enough that things crashes, different (broken) wireless driver (i didn't look into logs) is used, something odd is attached to USB / HDMI ports ... Try bare hardware, different SD card, different power supply, make a photo of PCB (revision, memory chip numbers, ...). Where do you think they took (stole as they didn't tell you where they got it) software, that looks the same as Armbian, from? FYI. All images are assembled the same way and builds are now even reproducible. Its highly unlikely that one image will boot and the other wont.

do not install WG it as: - its already present in all kernels - as their postinst scripts installs kernel from Debian repository that is not suitable to run on this device ... which breaks the system.

This is what it does: https://github.com/armbian/config/blob/master/debian-software#L830-L863 It adds normal user, under which will be installed, if not there, and proceed with their script.

Perhaps it doesn't work. More resources / ideas / background: https://www.google.com/search?q=blacklist+USB+UAS+armbian https://www.cnx-software.com/2020/08/12/how-to-fix-unreliable-usb-hard-drives-stalled-transfers-linux-windows/ https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)

We measure this automatically every day: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results 970Mbit/sec

Odroid N2 has poor USB implementation. You need to blacklist UAS support (which will slow things down) and it will work. Search forum (or Google) for tips how to do that.

It works: https://status.armbian.com/ Perhaps some network related issue.

This fixes it:

We don't use it with recent kernels: https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh#L47

I think the problem is Qemu on host machine. If host is not exactly what its recommended, something like that could cause issues. Try PREFER_DOCKER=yes

https://www.armbian.com/bugs

Yes, suggesting those images is our bug. I am aware that sorting doesn't work right but this is yet another problem we have to deal with. I have asked that this is fixed and since we don't have professional support It can take several weeks, perhaps a month. I can't fix it, I can just patch it, so I have removed those images for good and they will be gone from index within several hours. More then this its not possible to do. I am using this image for several months in production. Any many other people. We share this joy with you. Mainline based support functions rarely gets to full completion as its very expensive to brought things up and maintain with no budget. Adjust expectations, use old kernel, share findings with others, but don't expect anything, especially not answering questions. It can easily take hours, which is not at end users level.

More then expected. There are many warnings for you to read when you boot those images. Why do you think this is written: Only Armbian standard supported builds usually works well. Download it and enjoy. If you have problems with others, you need to invest your own time to fix, adjust expectations.

This myth is one of the places this whole business sales departments are targeting. If you and me understands the difference, most don't, even they are hardcore and long time Linux users, those who will buy hardware. "Android kernel" is as hardware support done in as cheap as possible way, presentation quality, its full of hacks and proprietary solutions, often with binary libraries. Often at this point vendor support ends. Most of HW vendors investments goes into sales, not into software development. This is reserved for others, often community slave workforce. Why I used this terrible word? Because force is normal MO. This forum and especially vendors forums are full of angry customers attacking developers to fix things. Those developers nobody ever paid or say thanks. Open source development is fun, but not when force and abuse is main drive. Everyone would like to have that, just the problem is that this costs several millions per SoC to develop and further to keep support stable. If they move money they put into sales rather to R&D, competitors will run them over in no time and they even see and treat us as competitors. Orangepi rather invested money to re-brand our OS and our build tools in order to look professional in front of their customers. It would be better for you and them to deal with hardware level issues, and maintain their stack as some others does. With our well maintained build framework that is mainline / as close to mainline as possible. They don't understand the value. Short term profits and ego are more important. Similar goes to Radxa. They mainly ignore supporting mainline problems but they rush to publish news that their hardware is supported by Armbian, while Armbian team didn't know that, its regular fake news, until yesterday as I stumble upon that. Now imagine their customer coming to Armbian and expecting support we never planned, knows nothing about, never wanted or have budget for. This is how vendors play dirty (with you and FOSS developers) and there is little we can do about. A lot of efforts goes into the clarification that we don't support this and that hardware and that support is best effort anyway ... Which means its possible nobody will ever answer or fix the problem. Anywhere, mainline, or with other Linux distro. Pragmatic experience working in this world since early days on top of 30 years of with Linux, 10 out of this in embedded Linux. I have no motive to picture things nicer as they are. Rockchip and many vendor recognizes our efforts but they do nothing to help us. Contrary. Some has dirty business practices also toward us, even we helped them a lot. Enlighten me?

Even there would be a big advertisement, a very few people would notice and care about. If we would rely on end users to provide information we need, even this is in their interest, very very few people responds. If you want to get proper attention, you need to invest a lot of time ... or someone else has to invest it. We collect data with automation: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results As this is not in armbianmonitor and as older boards are not very stable and thus offline, this is an afternoon of work, which you (anyone, ain't personal) would need to wait few years on it. Support for Armbian hasn't changed much since you stop contributing. You know what to do to get this data from the boards that are in the pool. Fork, PR, Thank you.

At the very bottom of Orangepi 5 download page https://www.armbian.com/orangepi-5/ "Rolling releases from CI pipeline"

Probably it just works now. There were many fixes applied to this area in past year and half. https://github.com/armbian/build/commits/main/lib/functions/image/initrd.sh