Igor

This was never even planned nor IIRC anyone asked for in past 10 years. End users usually doesn't need this kind of automation and if this is for your business, welcome to become a partner (cover some of expenses you are generating) where chances for resolving moves into positive direction. Here we are collecting ideas that make sense for everyone: https://forum.armbian.com/forum/38-feature-requests/ and that we can sponsor or finance from public charity: https://liberapay.com/armbian Every line of code is for project maintainers a liability and someone has to maintain it. The part of the code mentioned by @robertoj was introduced some 6-7 years ago and the one adding is long gone. We have many such cases all around and we all want that code doesn't have bugs and you want all this is free for you. This is hard to achieve. One way to patch this problem is by finding volunteers but very very few people are interested in doing this hard work ... Its not that difficult to resolve this, but we really can't do anything anytime soon, certainly not within one year, as we have many other things, that are important for everyone, in plan to resolve. https://docs.armbian.com/Process_Contribute/ Develop, test and implement a feature you need. If it will be done quality enough with low maintainace expectations and / or unit tests, PR will be accepted, else not.

You can find a working example within this script: https://github.com/armbian/scripts/blob/devel2/.github/workflows/build-test-image-docker.yml

OP was not using official tools and Odroid N2 is different beast. If you need that the problem is found and fixes, you need to provide EVERYTHING. Whole procedure on what you did and provide all logs you can ...

Another explanation. Every distro is maintaining their own kernel config. We (try to/have to) maintain 65 kernel configs ... and what you are asking is impossible to pay attention to. I have open a task https://armbian.atlassian.net/browse/AR-1803 but our capacity is pretty small and it takes 4 years on average that task is closed. To give you another perspective. And most of other Linux distros are just worse in this. They simply say - its upstream problem.

... Armbian bookworm. Everything that is important is coming from Armbian. We keep relation to upstram release name because standard user land packages are coming unchanged from Debian. But they are assembled different as on stock Debian. Networking is ours, first install, installation, ... A lot more is changed then on most of Debian based distros. There is a way. Build kernel, dtb and headers package with https://github.com/armbian/build and install to your image, reboot and then proceed as what was your original intention. It looks like its just not enabled. When you will be compiling kernel, enable this https://github.com/armbian/build/blob/main/config/kernel/linux-rockchip64-current.config#L3362 and perhaps that will be enough? You are welcome to send a PR to changes. For externals - DKMS is nice as - we provide mechanism, you deal with the rest - bugs in the driver code that prevents compilation. We cover many https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh but adding and maintaining represent serious commitment.

Even almost nothing usable works, when first bits of CPU support is merged to the Linux kernel, such news is produced. It can take years before chip is actually usable and sometimes support never become usable. Here this is not the case as its a popular chip and support is being developed, just procedure to get into the kernel is rigid, takes time. Term "officially supported" by Linux is IMO very overrated and not sure this term exists at all. Armbian mainline based images for 3588 are floating around forums, but ofc no official supported builds with modern kernel yet.

There are few problems associated with a small problem you have. Lets just name a few: - we are afraid to push out kernel updates and potentially break thousands of deployments. We can't test those upgrades well enough and because we can only do partial upgrade at this moment. Yes, I know you will offer help to test, actually a lot of people does, but when we ask "now we really need your help to test" just a few does and we are again down to our too small in-house testing and automated testing, which nobody wants to help us maintain. If its not maintained and developed, automated testing does not help. We need constant help from you and also deal with this problem on the level I am mentioning. Many many areas are only covered by one person and if that doesn't have time, whole system has to wait. - few months ago we changed to completely reworked build framework. All support script and automation become deprecated over the night and we are still making new ones. - repository management become deprecated, but we managed to setup a new one. But this new one is not matured, was not tested well enough and we keep finding problems. Before this is not fixed, we can't push out update. - kernel headers are handling with armbian-config since we are providing headers per kernel family, not just per version. This adds another level of complexity and the tool itself, armbian-config is not maintained anymore as we are building new one, from scratch. We are re-starting refactoring of this critical tool now for the 3rd time. Just to remind you, there is no budget whatsoever, while hundreds of hours were already lost getting absolutely nowhere. Which is sadly completely normal part of software development - most project fails. - kernel headers compiled for Ubuntu user-space might have troubles in Debian user space and vice versa. This problem is addressed, but only extensive testing will tell us if we manage to overcome this problem. All this is possible only because we supports this project heavily. You are welcome to join and help us fight those problems. Workaround to resolve a problem just for you - build an image with enabled headers or use previous major build, which headers and source install will work via armbian-config, as per design.

Try EDGE kernel. Module for WG should be already in. For this 5.4.y kernel we need to look why headers are broken ...

Here on forum. https://www.armbian.com/bugs/ ... logs helps, but as this was already known and confirmed, no need. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts?h=v6.3.13 As you can see perhaps some boards will boot and serial console will be working. If you are satisfied with this kind of official support, we can save a lot of time Linux 6.3.y is EOL BTW There are some experimental builds around that are usable to some degree, but without any official support. Unknown / undetermined. Pay attention to our news: https://www.armbian.com/newsflash/armbian-leaflet-9/ (and new ones) https://docs.armbian.com/Release_Changelog/

This is Raspbian & Raspberry Pi proprietary config file you won't find it anywhere else. Every HW vendor has its own config way, Armbian keeps this consistent regardless of hardware. Correct. extraargs=boot_delay=30 that would would be passed to the kernel. But as you already figured out, this doesn't help in the problem you have. I would dig into documentation of network manager or systemd-networking, depending on which way you plan to configure your network.

This can only means one thing - you didn't read forum or documentation well enough. https://forum.armbian.com/forum/203-software-applications-userspace/ , second pinned topic. The rest is not Armbian specific and I would need to research too.

Nobody knows what you are running. All those images uses Armbian kernel, so its either you are using a bit older version or there is some user space settings, hack or parameter that makes this diff.

Great! I think uidmap package can probably be added to the default package base. Contribution should be trivial: https://github.com/armbian/build/tree/main/config/cli (need to be checked if exists everywhere - probably it does) https://docs.armbian.com/Process_Contribute/

Try this https://github.com/containers/podman/issues/2211

Few hours before leaving for vacations, I found out the same. I didn't have time to debug ... there is something wrong with u-boot / ATF settings. We have some ideas but I am out of office and can't test. Thanks for your offer, but sadly that helps little. We have virtually unlimited access to cheap hardware - most vendors happily send us whenever we need them - one engineering hour costs more then one hardware pcs. Time is a problem. Not many can afford to work weeks and weeks straight and pay all the living expenses. To support competitors that skips all this and for you that usually don't even notice or care. (generally speaking) Allwinner wise, not just this SoC or this board specifically - for https://armbian.atlassian.net/browse/AR-1502 we wasted several weeks, we made some progress, we made expenses to upgrade test gears, we lost hundreds of hours ... nobody even noticed. If you want to help improving support, help with your time and expertise. I can sent you a free board too

How is your network configured? Which tools do you use?

add a switch EXPERT=yes

You are welcome to sent a PR https://github.com/armbian/build/blob/main/config/kernel/linux-rk35xx-legacy.config

With many patches taken directly from Armbian 6.1.y, but there are few more so its worth investigating.

We are aware software support for Allwinner is slowly but surely collapsing, so this is the plan https://armbian.atlassian.net/browse/AR-1502 There is no support from any side, not from users, not from industry, budget is negative and we already lost lets say hundred hours for preparation and meetings, without counting the work on the code that is already in motion. Just to improve this section. We also purchased some additional devices so we can monitor upgrades better ... To save time answering this question. If you build image from sources, it will work. I just did it earlier today: https://paste.armbian.com/amufuxisen

Problem you have is not possible to reproduce by using latest source from main branch. Which is the only source that can be maintained. If you are using different sources that the main in main branch, you need to adjust them accordingly. Build framework needs clear instructions and code that builds. IMO its less work supporting our common goal - get this working with latest version.

Installation is not the strongest part yet as we are developing / extending our own installer. Installation is possible but its easy to hit into problems: https://armbian.atlassian.net/browse/AR-1592 (probably others yet to be found) Thank you for trying and encouragements!

It is temporally issue that is present in Rockchip kernel for at least 6 months. And its not the only one. With modern kernel, headers works OOB, which proves bug is in the (Rockchip) vendor code. I already spent a week trying to fix this problem for everyone but I can't afford to touch this problem anytime soon. If there are no records of fixing this problem in the logs, update mentioned in the leaflet, won't fix this problem.

Thank you. It was never Debian but Armbian (with Debian user space packages) since the day 1 but at some point we had to stop maintaining hw interface / kernel, also Kobol went out of business. When this happens, things starts to fall apart and if you would take our work more serious, you could have this hardware well supported.

You mean Linux kernel related troubles? Documents about progress and problems is scattered around many forums and mailing lists. We are focusing to troubles related to hardware we cover, but there are also general problems we all face. If you have a lot of time, if you are dealing with this daily, you can get a better picture about, but it will be far from complete. I only told you how I see it. If you are talking about build framework documentation, than yes, its not in a good shape. We have reworked framework completely and made a switch several months ago. We had to, even documentation was not completed yet. Person who had to deal with this couldn't afford to continue working on that, while I can't hire a person as users want everything for free. Recently I have started to engage with another person, to put documentation together, but he needs weeks / months to get familiar ... Build framework supports it, but we don't use DOS partition to store DTB files and yes, enabling UART is just editing it and enabling within. Or by make + loading overlays that contains that change. I understand users frustration. This is not a professional support service and there are 1000 x more people that asks questions than those that can answer. This ratio hasn't been changed in past 10 years and it won't. Its a complex world, a lot of time has to be wasted to answer and users (including experts like you) don't care about perspective from the side you are addressing to. Reality looks this way: to answer you, I had to tell my wife and my kids to shut off as I have to focus to answer to someone that is stealing our family budget, to answer everyone that needs help, I can waste all my wake hours every day ... and you are pissed off? Nobody here is responsible for troubles end users have - this is the base of our contract. If 3 days response for hardware that is specifically marked as "not supported" on the project that only provides best effort support via forums is too much, we provide commercial support - which is just one way to respond on violence from people that think we are responsible for the misery and we have to solve their problems. No, we are not. We are in this sh* together. Just we spent 24/7 to work on problem, we pay for most of costs and for most of you this is a hobby. Neither me and many people around here. Scene is also changing. Market is overloaded with cheap hardware that is becoming more and more complicated ... while back in 90" it was a huge privilege and thrill having a root access to some big bad-ass Unix machine. We don't have time for holy wars here, Debian vs Ubuntu vs Arch vs FreeBSD vs ... That part is so not important for the problems we deal with.