Igor

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

After few hours to figure out how to properly tune this config https://github.com/armbian/os/blob/main/userpatches/targets-all-not-eos.yaml right files are generating now. Main rsync has files, while it might take few hours before index will be updated on all mirrors. https://rsync.armbian.com/apt/pool/noble-utils/b/base-files/

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: