Igor

@tony013 I hope I didn't scare you with pointing out to our testing rig I mean it serious. We can't afford to rely on manual testing. It needs a lot of coordinating and time. All serious developers have such tooling ... We have built this test system together from scratch, which is obviously a lot more efficient than manual testing, but driving routines are still immature and under development. We only have some quickly assembled bash scripting, network for test devices is more or less ready, netbox DUT inventory up2date, ... If we are focusing to the bug fixing in this release, perhaps rather fixing bugs that are already on the table / known / short term? Do we have enough time to bring as proposed up, test well and push it into upcoming release? For many people it's also a start of a summer holiday, which could add delays. BTW. I also started with a "Code cleaning" task, which anyone that feels bored enough is welcome to join. No functionality changes, just cleaning things out, rewriting things better, moving functions here and there.

This difference is extreme, especially in custom interesting features, so it's usually not a simple question. Moving functionality from private nonstandard kernel 4 to mainline 5 can easily eat a million which is why we deny all such pleads in a as quick as possible manner. Especially in this case, since Nvidia is notoriously non-cooperative with open source. Not sure if anything has changed since. By helping the project, by taking some load of from our shoulders https://forum.armbian.com/forum/54-help-wanted/ you help. Yourself and others.

... A64 board where you only need to solder battery.

This is forum - you are welcome to talk about, but demanding support is a bad idea. You can report bugs here but only if you pay commercial price for fixing it & if we agree / are free to accept a deal or if you will be the one fixing it. By who? Why? Several years ago (i would estimate about 5 years) we have concluded its not possible without breaking others or without severe framework customisation / rework ... This is when incompetent people are making hardware and when you expect software can fix all those mistakes in this chaotic world. And you also believe we have to waste our private money for that. Attitude. Open source is not slavery.

If feature in private kernel works, but it doesn't in a kernel that vendor doesn't support, answer is in such manner.

Actually it is, but perhaps not well exposed in documentation: ./compile.sh 'compile_uboot'

If one variant (Buster, Focal, with or without desktop) doesn't boot, all others won't - low level support is identical. But you can check images from archive (last link on the board download page) since its known that they worked in the past, but we still didn't get enough interest from your side to improve / develop (automated) testing. Manually testing of each released image or covering development of testing team is something we can't afford. Not even close. Do you perhaps have a serial console so you could provide some debug?

You are building this on what host? You have supplied not a single clue about that most important. There are also detailed logs in output/debug which might contain critical informations. We are rebuilding images upon upstream changes: https://github.com/armbian/build/actions/runs/963008795 https://github.com/armbian/build/actions/runs/961942368 Are you sure you are using our up-to-date build tools? Full build log on my Linux Mint workstation:

Should be fixed with v21.05.6

Try perhaps this: apt install slick-greeter + reboot.

I hope (official) support terms https://github.com/armbian/build#support won't scare you ... but IMO you should understand right away how things are, before asking for more. We have zero financial coverage to fix bugs in corporate business software https://www.kernel.org/. In one year we collect just enough cash to cover expenses of digging into one such bug, but sadly basic costs needs to be paid if we want to play around those things. tl;dr; Also terrible is general misperception - people that are paid to work on issues as such would take a week to dig in and remove the cause while most of users expect instant resolution and pay nothing. Sadly, we don't have a week and there are 1000 other bugs pression on way too small team of people that have interest to fix things in common good. There are just a few people that maintains this complicated system.

https://www.zdnet.com/article/google-should-really-open-source-chromium/ https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

All three customers that are complaining here - start with an Angel monthly subscription and it will be quickly enough to cover expenses to fix this bug. Donations are reserved for free willing acts which btw don't cover electricity costs. I wouldn't call that as essential.

I doubt that has changed, but possible. There are some default values, but we overwrite those with our boot script: https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd Here you could experiment with values. Each time you edit /boot/boot.cmd you need to convert it to boots.scr https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd#L92 You can also override number by editing /boot/armbianEnv.txt which is plain text file. I am not sure my prediction stands. Its just a hunch worth working on. And this problem is not directly related to Armbian (tools) so you will not find any documentation on this topics there. Perhaps here https://linux-sunxi.org/U-Boot or within u-boot documentation in the code or by looking into the code. That's how our world looks like ...

Possible cause is ZRAM / ZSWAP implementation. Try disabling or / and move to kernel 5.12.y.

We need many different profiles of people to run this project and just about any help, help on development. Since in other case developers have to fix web pages, developers have to run projects, developers have to seek for money, developers have to maintain servers, developers have to maintain forum, developers have to moderate forums, developers have to maintain infrastructure, developers have to maintain relations with partners, developers have to waste time on repeated support question, developers have to deal with "customers", ... This is amateur supported development so this information can't be provided. We don't know when things will become stable - that is the most expensive part. If we stop with development, we only gain - I would say you should do something about.

Locking topic. Your questions are on the 1000 USD per question level.

Referencing to Bananian has zero value and we are totally fine if it works there, but not here. It's the same as referencing to some random years old Armbian build, where this, I am 100% sure, worked well - up to some point. Why it doesn't work anymore? Without spending few hours, which is not possible to happen, not possible to know. Also something tells me you might not be using latest kernel (you have to provide logs each time you want to discuss something like that - not logs you think are enough) - due to other issues - which means you could run into random error, related to wireless subsystem, which was fixed upstream weeks after. Linux kernel is a messy thing and nobody will waste time to fix problems in some older versions / builds. Not even for (good) money.

That is probably related to the ampak firmware / chip revision mess. Which we will not even try to fix.

Have you done apt update and upgrade? Bug was already fixed and pushed out, but ofc this can't be fixed on already published binaries. Which are usually changed only at major releases.

How about this way - "Sadly we ran out of money to fix things for this year. In reality already second day of the year.". But hey, this is open source. Anyone can fix things. It is. That would be some workaround but sadly we have no ability to effectively communicate such message.

Do you support the project at least this way? https://forum.armbian.com/subscriptions/ So you don't make additional expenses when asking for support you are far away from. Software development and support / bug fixing takes time. It is also very expensive since people needs to have a lot of knowledge which is highly paid and very desirable on the market. Here you expect this service for free. Well, then you have to wait with a partially broken system without complaining ... also you can fix it on your own. Or hire some to fix this for all of us. Why this would go on our private expense??? There are "1000 bugs and 1000 people" before this one and this update fixed some other bugs. We made few people happy, but not possible to make all happy. Bug was recorded to our system and its waiting for a free time slot. For our donation to you. A week, a month or years. Up to you.

In the past few weeks I have been working to improve processes of deploying our work. Scripts that runs in the background are combination of tools that are build into the main tool and additional scripts that run on the server. They are (will be) summed in a (private) scripts repository, but the functioning - which could be interested for any maintainer - are summed in this document: https://docs.armbian.com/Process_CI/ Welcome to add your ideas, especially for the merge request part, which remain unchanged. Otherwise its planned to extend this automation to execute tests, similar or the one from @William Bonnet on virtual image (image already boots insite Github actions) and real hardware (need implementation). Examples: - updating images and kernel update for families that those boards belong to: rockpro64, station-p1, station-m1, odroidc2, odroidn2, odroidc4, odroidhc4, odroidxu4, nanopir4s, udoo, cubox-i, rockpi-s, rockpi-e, rockpi-n10. nanopct4, espressobin, tinkerboard - building under Docker and booting qemu image inside Github action (WIP, not enabled yet) - upstream kernel changes for a few families caused rebuild and updating of both repositories

https://armbian.atlassian.net/browse/AR-749 Probable cause is that one of the files (dtb, image, ramdisk) are overlapping which means same kernel version (that is smaller) boots, while a bit more features not. Problem is known for months, but our resources are only a tiny fraction needed to keep up with problems that pops up. If you find out right numbers / fix the problem (for everyone) https://docs.armbian.com/Process_Contribute/ Before you start, check self created image (https://github.com/armbian) - perhaps its already fixed.