Igor

If you would like to use 2 years old kernel with not a single fix applied after initial release, use version of Armbian from Orangepi site. This question was answered on Orangepi download pages. For everyone. To spare answering same questions over and over again. Which is devastating for mental health and expensive when we pay everything and you nothing. Only when you like - donation.

I change the text to: "we will be able to proceed once your donations for entire project reaches at least 1000 USD per month. " Even this miracle happens, we will still be making a huge loss, supporting mainly subjects that compete with us with our money (Orangepi is one of them, stealing value from us in order to sell you cheap hardware). That far away we are. I am sure GitHub supports all kinds of payment methods and random donations method supports that too. If you ask us to repair something, donation doesn't works. That is a professional service, which are paid at standard rates - this is for vendors that doesn't contribute in any way. Fixing resources are expensive and scarce. This is open source - shitty operation are not Armbian problem, but Orangepi, yours.

This is the only "fix" we can finance from your donations: "PCI support is broken on vendor kernel (6.1.xx) on versions higher then 24.8.1. Use this version and freeze kernel (armbian-config -> system) prior to updating OS. PCI works on other Rockchip 3588 devices, while fixing this on all represent expensive technical challenge which we can't finance. With Orangepi devices we have extremely high negative support budget while your yearly donations are not on the level to compensate this loss. Alternative operating systems that relies on our work face the same problem. We appreciate for your understanding." https://www.armbian.com/orangepi-5/ So does previous Armbian image. Use provided instructions or only buy (probably a bit more expensive) from vendors that supports open source developers.

Can you provide screenshot and some logs (armbianmonitor -u)

Usually catching last week. If you have followed instructions on download site, https://www.armbian.com/odroid-m1/, then you have u-boot. Which is fine.

Switch to nightly build and try. Or just wait few weeks for 2024.11 update. Are you perhaps booting with petitboot? We fixed this some time ago: https://github.com/armbian/build/pull/7245

Probably what you are asking works, best to just try image on something, perhaps VM. I only use one (1) official add-on, which is Z-wave ..

Probably related to NVME and those two commits: https://github.com/armbian/linux-rockchip/commit/16a7adc42e350ee3ff96298f295ae01f52f103bb https://github.com/armbian/linux-rockchip/commit/a095b986015598f2aa1ef1e424f766a8bb65f4a3 This fixes SATA bridge on Rock 5 ITX but possibly breaks NVME on Orange 5. As we will not maintain another special kernel for a single device, Orangepi 5, we have implemented a mechanism to prevent upgrades beyond 24.8.1 https://github.com/armbian/build/blob/main/config/boards/orangepi5.conf#L17 which might not be working properly - It should block upgrades to this kernel ...

Welcome to try with integration to https://github.com/armbian/configng We didn't set rules how to include tools from external repo yet, so this is a bit wild ... - there are unit tests in place for each command - automatic documentation generation is WIP

Will log you out automatically, at least when running desktop. In case one is running Google Chrome, this will lock it out This 10 years bug is still valid: https://askubuntu.com/questions/476918/google-chrome-wont-start-after-changing-hostname BTW. We are switching to armbian-config new generation soon and here this is done this way: https://github.com/armbian/configng/blob/main/lib/armbian-configng/config.ng.system.sh#L33-L38 If you have ideas for improvements, welcome.

That would be network / mirror sync issue. Try by adding this switch: SKIP_ARMBIAN_REPO=yes

I wish this would be that simple First, all distros are (usually) re-building packages at different time, thus by default bringing different code base. That change can be small (using same main version of kernel) or big (6.1 vs. 6.10 for example). Then. Armbian adds (ATM) 436 general patches to the kernel and we add several 3rd party drivers to the kernel. We actively maintain this kernel, unlike others. Some distributions are using our kernel, while OpenWRT AFAIK not. Which means they use some version of mainline Linux kernel with their own patches. Their focus is networking (protocols), so I would assume they are fixing those things. I doubt they are doing anything related to this hardware (wifi chip) besides adding device tree (if not yet in mainline). Fixing wireless drivers in its core is done by very few people that are not tied to any distribution in particular https://github.com/morrownr/USB-WiFi https://github.com/kimocoder ... experience will be different, especially in area of this particular hardware.

Its usually hardware / quality of the driver ... but ofc also "something in between". Armbian config way has been significantly improved, worth trying upcoming app: https://github.com/armbian/configng

We keep several oldies in the automated testing facility and Cubietruck is almost identical to Bananapi M1 and it works perfectly well: https://github.com/armbian/os?tab=readme-ov-file#cubietruck I would put my bet on wrong / not sufficient powering. Which is still there and those (old) topics are still valid. Old boards are fine! I have several boxes of them and might sent them to a museum one day We are just too small team / project to face with several hundred different devices. Old boards should, in theory, works well, but silent (as nobody monitor / maintain them) regressions comes to the code. I hope someday dedicated retro hardware section emerges on Armbian forums and further prolong life of those devices. We did / do what we can ...

I assume standard 1080p monitor? Can you grep logs for errors? Will try to reproduce when I find time. @TonyMac32 When was last time you hooked a monitor to Lepotate or similar device?

Here you can find few old builds: https://github.com/armbian/community/releases Main archive is reserved for (once) supported targets on our infra and we are already at current full capacity and (very) old archives are held only on big storage servers.

Open PR similar to this one https://github.com/armbian/os/pull/254 it's faster. I can execute build, but can't test.

Rpi works fine I am sure https://www.armbian.com/rpi4b/ while for not supported / abandoned hardware we don't know. But you can still try to get it up one day. Serial console logs - without, its like nothing happened.

[Task:] Adding Armbian to Fastfetch https://armbian.atlassian.net/browse/AR-2336 [Task:] Adjust OpenHab official documentation https://armbian.atlassian.net/browse/AR-2387 [Task:] Create github action to refresh kernel config https://armbian.atlassian.net/browse/AR-1827 Any of those counts. Still two weeks to go.

That is not Armbian. It must boot OS that is preinstalled on eMMC. You need to erase that somehow.

Mirror sync mechanism has its flaws - trying updating later (now) should resolve this problem.

There are (too) many different models & making hardware was never this cheap ... The closest to this were @chainsx maintenance of LicheePi 4A but it turned out bad. Framework has all needed mechanisms which is what we maintain. That help that this job is easier for anyone that wants to do it.

There are no examples for Allwinner variants, but it goes the same as for Rockchip - copy working dts here: https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.6 under dt/ folder (Example for Rockchip: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip-rk3588-6.10/dt) + compile + test + submitting a PR. BTW. Cool Neofetch