Igor

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

Yes, I am working on that.
Whiptail is what I am educating me in closer right now.
 
But it will most likely be it's own script. Trying to implement the script straight up I think would become messy pretty fast, and I don't think anybody is interested in that.
 
But yes, it is happening, sometime.. xD
I was honestly hoping it would already be a reality, but my health keeps putting up roadblocks for me.

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 ... 

The official image works as it should. 
The edge image may in time be fixed when whoever is working on the changes finishes. It is called the "bleeding edge" for a reason. One can not expect all things to work properly with edge images.

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 ... 
 

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

Hello everyone,
 
I’m the original poster and I’ve been successfully running Armbian 23.1.1 on my Orange Pi 3B v1.1.1 for 60 days.
 
The image I used is Armbian_23.11.1_Orangepi3b_bookworm_edge_6.6.2.img.xz, which I downloaded from the Armbian archive https://archive.armbian.com/orangepi3b/archive/
 
$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Armbian 23.11.1 bookworm Release: 12 Codename: bookworm  
I successfully used armbian-config to switch to a 6.6.39 kernel:
 
$ uname -a Linux latita 6.6.39-current-rockchip64 #1 SMP PREEMPT Thu Jul 11 10:49:22 UTC 2024 aarch64 GNU/Linux  
Thanks to @heyrict and  @Igor for their feedback!

https://docs.armbian.com/Developer-Guide_Adding-Board-Family/

I found and fixed the problem, and of course, it is the PSU. TL;DR: use a USB-C PD 2.0 power supply that can provide 35W for a single USB-C port.
 
I bought the Banana Pi M7 from this Amazon page, and the seller provides a power supply, with the board, that can only provide up to 20W of power. Even though the board specification says "Power Input: USB Type-C PD 2.0, 9V/2A, 12V/2A, 15V/2A", which implies that the board can require up to 30W of power. This caused most official images (Armbian and otherwise) to fail to boot. I happened to have a USB-C charger that can provide 35W of power, so I tried that instead, and it basically solved the whole problem. I tried multiple Armbian official images and they work as expected.
 
Thank you for your help! I hope this helps someone.
 

Just guessing. Sometimes armbian-install seem to fail to populate /boot or the UUID of the nvme is wrong.
Try this: clear mtd and nvme, boot from fresh image from microsd, maybe remove emmc if not needed.
 
Do armbian-install and let it move OS to nvme and flash spi.
Do not reboot. Mount the nvme again somewhere and check if /boot is populated. If not, copy everything manually from microsd/boot to nvme/boot, then use lsblk or similar command to get the uuid of the nvme and edit the freshly copied armbianEnv.txt to match the uuid.
If /boot on nvme is populated already make sure the uuid is correct.
 
Then shutdown, unplug, remove sd and power up again.
 
For best chances debugging boot issues set verbosity to 7 in armbianEnv.txt and check the video at https://debug.armbian.de
 

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.

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.

Download Armbian with OpenMediaVault (OMV) 
Currently (for testing) only 4 targets were build: rock5-itx, odroid m1, odroid xu4 and x86. Once its confirmed that works well, other targets will be assembled. 

Then boot the image, wait few minutes and login via:

http://ip_address_of_armbian_running_ha
U: admin
P: openmediavault
 
Test setup on Odroid M1:
 
 
Tested on:
Odroid M1 Raspberry PI 4  
DIY

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

@Igor this recent fix seems like it: https://lore.kernel.org/all/E1sbJvd-001rGD-E3@rmk-PC.armlinux.org.uk/#r
 
apparently the driver was decoding the duplex mode incorrectly.

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

@Igor It did. Thank you. The final PR will be here: https://github.com/armbian/build/pull/7216

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

Hello @Igor, thank you for the update.
 
I understand the predicament for lacking enough resources given the scope of the project and I don't expect things to work OOB without testing. I've updated the package list via apt and now I can see the headers package now for the current-rockchip-rk3588 Linux kernel (along with a the new linux-image .deb package). I have installed it and can confirm that dkms works fine to complile the WiFi dongle's driver - though it's not fully working yet, though this is purely a driver issue, not related to Armbian/Debian.
 
Thanks for the updated kernel packages.

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

Orangepi OS (Arch) is custom / re-branded Manjaro and Manjaro is not doing much else then shipping (selling) their Arch derived OS while taking our and community work on kernel maintainace. This is the story how Orangepi "supports" open source - by primarily supporting code dealers that already mainly have negative contribution to open source development. But who cares other then small group of people called "developers"?

In general, HW vendors have interest to block or at least control other OS providers and it is possible they purposefully compiled SPI boot-loader to not load anything else then their OS. This would explain why you can't load our OS. Manjaro already provided (or tried to) this "solution" to Pine64, so average users would have troubles changing OS. Details: https://blog.brixit.nl/why-i-left-pine64/ 
 
For us, this is easy to work-around, but bulk of people might still need to stick to their official promo/spy/pirate-ware.
 
Solution?

Debian based OS:
 
sudo apt update sudo apt install mtd-utils sudo flash_eraseall /dev/mtd0  
Arch based OS:
sudo pacman -Syy sudo pacman -S mtd-utils sudo flash_erase /dev/mtd0  
Then boot armbian from SD card and run:
 
sudo armbian-install  
And choose "update MTD boot-loader" or "Install it to NVME", which will also update boot-loader and transfer image to SSD. Tested right now with Opi5 lying on my desk.

I read about this on this forum or chat. Try this way https://forum.armbian.com/search/

Thank you very much. Installed the specified image. OMV has started. Now you can test it.