Igor

You are using old image on non supported board. Did you made a full system update prior to installing code? This would explain it. Our daily automated install on x86 platform shows no problems so it must be limited to 32b armhf system, which is getting less and less love generally. If you have updated everything .... this is beyond Armbian anyway.

Project you are mentioning is one person pirating Armbian authors. Dietpi is not contributing to common work. He is making up an impression of development and support. They are even selling fabricated / falsified comparison between dietpi, debian and armbian for years. Most of people buys this as they have either no ability to understand or they don't even think why would someone, in providing software that is free, has a motive to cheat and lie. You are running our work, bugs included, ... while you are paying him and promoting his (our) work on our forums? Why? Since you didn't know nothing about this, it means he also successfully stole credits from our work. If this happens to one person, its perhaps nothing, what about if 10.000 people thinks this is their work? What would you do when someone would sign himself under 100 hours of work you will be doing for work in public good? What if you will donate 10.000 of your private hours or more and he will keep providing your work under his name? Software support, stabilisation, ... is the core value here. We do provide you good and stable operation and we lost tens of thousands of hours. While most of their users compliment them for this work, while they never contributed anything to that. This is how piracy works in open source world and they use this to great extend. There are many solutions as your hack, but they are lost on forums. If you really want to help others, you need to implement a fix into a build framework https://github.com/armbian/build Why you and not us? Because small team, people don't support not even close to what is needed to keep up. And we have to fight bad people / projects, you might be supporting, within time that is available. When we lost that hour(s), everyone will gain with our sacrifice, while copycat project will not suffer any loss. Multiply this by 1000 cases (Hypothetical) for example which we financially (your share is < 0.5%) and mentally cover in certain time frame. Informing you about piracy is also not a convincing argument as it is hard to understand and hard to accept. It is a lot easier to say that this is our fault and our choice. You seek gain and profits too. It is natural. If you use Armbian, you will only get less proprietary scripts, less vendor locking-in as a technical value. We need to invest a lot more into something that generates us only a loss. We can't do that without your help.

Can you provide logs with armbianmonitor -u Logout / login / reboot ?

This board is also known as armsom-sige5. Images are here:

Only if someone will step up and help (on long term). There is help on supporting hardware and getting important features working. While there is very little help in distribution, OS, automation ... https://github.com/armbian/os I am more or less the only person dealing with this and I can only keep an eye on mainstream problems, corner cases, such as this, never came to the top of the list.

Those have best HW support and here we can provide video acceleration support. That's why. Mainline based images are also available, but with limited functionality. Which is always the case.

How I did testing: 1. Download https://dl.armbian.com/bananapim7/Bookworm_vendor_minimal 2. Flash and boot (by using USB Imager - try that perhaps) 3. Boot logs: https://paste.armbian.com/vucakunoko Next: testing the same image just to make sure: https://dl.armbian.com/bananapim7/Noble_vendor_gnome-kisak Armbian_24.8.1_Bananapim7_noble_vendor_6.1.75_gnome-kisak_desktop.img Boot logs: https://paste.armbian.com/jobavuqeza My PSU is lab, no PD. Problem is 100% not on our side.

Aha, you mean SD boot works, but then it fails to properly transfer it?

1. Script build all changed packages every 4 hours or manually in-between: https://github.com/armbian/os/actions/workflows/complete-artifact-matrix-all.yml 2. If this is successful repository rebuild follows (rolling and stable) https://github.com/armbian/os/actions/workflows/repository-update.yml 3. Once finished, packages are pushed to rolling release repository http://beta.armbian.com (which is stable enough for this hardware and most of end users). As kernel covers many devices, pushing to default stable repo https://apt.armbian.com happens manually after observing this https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results None of other distributions or distributions provided by vendors have this kind of quality control. Sadly, not even this is enough, but better we can't afford.

It should work - depends on the hardware - for the one we don't support, its unknown, for supported one we will try to fix in case of troubles. You can call armbian-install directly, so you don't install dependencies from armbian-config. There will soon be much lighter version of it, but current one is not very light.

Yes. Little more data is needed, like full logs via armianmonitor.

Yes, most likely broken / incomplete driver. Desktop runs Network Manager and CLI / minimal systemd-networkd. If driver is not in a good state, this is how it could manifest. Possible workaround = build CLI server image which contain Network Manager. No warranty that it will work ... Topic was moved from https://forum.armbian.com/forum/25-beginners/ as Armbian don't work with this vendor / hardware so its on you (& community) to resolve the problem. Or not. When you find out what is the problem, you are welcome to share it with everyone.

Just boot up and share your experience. Armbian is community developed general purpose Linux distribution, very different from commercial corporation controlled HyperOS. What applies for Armbian, applies for Debian, Ubuntu, ... You can run any software you want, but this is your problem. 3rd party software is not in Armbian, Debian, Ubuntu, ... domain as we are not authors nor re-sellers of software you seek, but anything Debian / Ubuntu (router SW) will work out of the box. You can search, try to connect with people that are doing something similar in this community. I am sure you are not the only one with such idea. Software is not attached to any particular hardware. This can be run or not run on all boards with at least two network devices = most of them. Armbian is also different for every hardware: Armbian team never supported anything TV boxes while many people, blame us for terrible user experience on hardware we don't want to hear about. By buying trash from Aliexpress you only support shady hardware dealers that are all abusing promise of open source software to generate sales. And you subsequently forget to contribute anything for the real work. Why would you support open source development? Experience is terrible and we can not change it. We don't want to support shady hardware. They save on components, have no intention to support open source in any way and software support on randomly assembled hardware is just more expensive. Every week several new models shows up that are assembled from random components. This is nightmare to support, especially with complete absence of expenses refund.

Made a PR https://github.com/armbian/build/pull/7245

Before: [ 5] 0.00-1.00 sec 63.5 MBytes 532 Mbits/sec 250 22.6 KBytes [ 5] 1.00-2.00 sec 71.2 MBytes 598 Mbits/sec 234 21.2 KBytes [ 5] 2.00-3.00 sec 68.6 MBytes 576 Mbits/sec 246 25.5 KBytes [ 5] 3.00-4.00 sec 68.5 MBytes 575 Mbits/sec 250 26.9 KBytes [ 5] 4.00-5.00 sec 68.6 MBytes 576 Mbits/sec 243 18.4 KBytes [ 5] 5.00-6.00 sec 67.9 MBytes 570 Mbits/sec 252 29.7 KBytes [ 5] 6.00-7.00 sec 68.9 MBytes 577 Mbits/sec 248 28.3 KBytes [ 5] 7.00-8.00 sec 67.2 MBytes 564 Mbits/sec 250 28.3 KBytes [ 5] 8.00-9.00 sec 70.1 MBytes 589 Mbits/sec 242 15.6 KBytes [ 5] 9.00-10.01 sec 69.8 MBytes 580 Mbits/sec 243 19.8 KBytes After: [ 5] 0.00-1.00 sec 87.4 MBytes 732 Mbits/sec 143 24.0 KBytes [ 5] 1.00-2.00 sec 92.1 MBytes 773 Mbits/sec 153 65.0 KBytes [ 5] 2.00-3.00 sec 89.1 MBytes 748 Mbits/sec 165 39.6 KBytes [ 5] 3.00-4.00 sec 89.2 MBytes 749 Mbits/sec 167 31.1 KBytes [ 5] 4.00-5.00 sec 85.8 MBytes 719 Mbits/sec 180 38.2 KBytes [ 5] 5.00-6.00 sec 88.6 MBytes 743 Mbits/sec 173 12.7 KBytes [ 5] 6.00-7.00 sec 88.4 MBytes 741 Mbits/sec 171 59.4 KBytes [ 5] 7.00-8.00 sec 89.9 MBytes 754 Mbits/sec 158 28.3 KBytes [ 5] 8.00-9.00 sec 89.0 MBytes 747 Mbits/sec 164 21.2 KBytes [ 5] 9.00-10.01 sec 87.6 MBytes 729 Mbits/sec 182 39.6 KByte

Expected. It uses nmcli to deal with network. We are re-working this - welcome to join if you wanna do bash magic.

If patch was not back-ported already by kernel.org to stable branches, pull them into CURRENT and EDGE with a patch and we can ship an update right away: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.10 https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.6

This cheap (WiFi) hardware was pushed to the market in unfinished state and since ever, with negative budget this is the only way, kept at basic operational state: "does it connect?" "yes it does", "does it work satisfactory? "yes it does". "does AP works" "perhaps" as this was already difficult and expensive for time, but enough for all home users. Drivers are by Armbian only kept maintained to meet kernel API changes, while real driver maintenance was abandoned by everyone years ago. It is unlikely that what you are looking for will ever be fixed. But sources are open, perhaps. You only need to find and fix this problem or compensate someone weeks or months to get this feature fixed ... if you have a biz case / budget to support this. Without our maintenance work, you would not have this question in first place as WiFi support would be gone. I don't think you will find anyone that will do this instead of you for a feature almost nobody needs. Good luck. My 2c.

If you would provide all logs, not just what you think is the problem, armbianmonitor -u (its a part of board support package, armbian-bsp-BOARD-BRANCH), perhaps someone would see something. Approaching this blindly is very expensive for time. Which nobody has. Since it seems you have a very old build, it is recommended to start from scratch anyway. You can try to run this: update-initramfs

I assume you are still testing? Can you try kernel from beta repo? Switch via armbian-config or change armbian repo from apt.armbian.com to beta.armbian.com Wrote on mobile

Interesting. Perhaps extending this service? https://github.com/armbian/build/blob/main/packages/bsp/common/lib/systemd/system/armbian-firstrun.service At build time, this is cp to the image and enabled: https://github.com/armbian/build/blob/main/lib/functions/rootfs/distro-agnostic.sh#L400-L401 Script: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstrun All those files you can edit, compile image and try. I hope this helps in some way.

Try to remove armbian-bsp-cli-orangepi5 first or both bsp packages at once.

No, there is no difference on hardware interface. You can try kernel 6.10.y, daily builds, ... those brings changes. It is always: armbian-install https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb I don't have this device on my desk, so I checked with Odroid M1, boot from SD card, root on USB. Works as expected, so there are no troubles at armbian-install part, but USB is probably too flaky on C2 (since ever). Use older image and freeze kernel upgrades is a valid workaround.

You need to find out how to put this SoC into Maskrom mode ... connecting eMMC clock pin to ground will force it to boot U-boot from SD card. Check forum if someone write instructions for this board. Some other distributions are dangerous to run It is known that Manjaro tried to lock down boot-loader to prevent you from going elsewhere once you got there. Here you can read some background.

Releasing packages on repo was purposefully delayed for a good week in order to keep with another expectation you have - that release software is well tested What we help here is to lower % of breaking your old installations by delaying with releasing packages so images gives additional round of test resoults. Testing of one release exceeds budgets for hundreds if not thousands of times. If you don't help with testing, its impossible to test. And you don't / very little. There is nothing we can do and only everyone of you can improve this. If you want better service, step up, help us maintain some small part, perhaps automation for repository management? Which is related to your problem. More people, better organisation, faster and better will be updates ... or at least not worse. https://github.com/armbian/os/actions/runs/10762581915 Once this is finished with success, packages will be uploaded to the repo: https://github.com/armbian/os/actions/workflows/repository-sync.yml Then few cycles of repository synchronisation: https://github.com/armbian/os/actions/workflows/redirector-update.yml Followed by re-director update, which serves, in theory, only mirrors that are up to date: Someone needs to help maintaining this mechanism. If you expect drivers going up with the kernel, then you need to help here: https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh