Back in March I ran into problems with the community builds for the NanoPi Neo, for Debian Bookworm.  It would boot up initially, but within 30 minutes or so, it would crash.  So I did a fresh install from the last official build I had saved from June 2023:

Armbian_23.5.2_Nanopineo_bookworm_current_6.1.30

And then I froze these packages to keep the working firmware and kernel:

armbian-firmware/bookworm,bookworm 24.2.1 all [upgradable from: 23.05.1--1-SAfece-B6ae3]
linux-dtb-current-sunxi/bookworm 24.2.1 armhf [upgradable from: 23.05.1--6.1.30-Sa343-D8bc9-P73a0-C162eHfe66-HK01ba-V014b-B9c18]
linux-image-current-sunxi/bookworm 24.2.1 armhf [upgradable from: 23.05.1--6.1.30-Sa343-D8bc9-P73a0-C162eHfe66-HK01ba-V014b-B9c18]
linux-u-boot-nanopineo-current/bookworm 24.2.1 armhf [upgradable from: 23.05.1--2022.04-Se4b6-P6b27-H0429-Ve2df-B91a8]

 

I know there are newer official builds from when it was still supported, but I can't find them available for download anymore.  Do you know if there's an archive somewhere that would have it?  Thanks.

https://archive.armbian.com

Thank you!  It looks like what I had was pretty close, anyway.  The last one was:

 

Armbian_23.8.1_Nanopineo_bookworm_current_6.1.47

 

from August 2023.

dear dave3, 
Have you encountered the problem that when recording Armiban to an SD card, the nano pi neo air does not appear on the PC as a com port? If I install the old version of Armbian 5.73 and connect it via USB to the PC, it sees it as a com port.

I don't think I've ever tried to connect the NanoPi to the PC to access the SD card.  I didn't know there was such a thing.  I just use a usb SD card adapater.

> Back in March I ran into problems with the community builds for the NanoPi Neo, for Debian Bookworm.  It would boot up initially, > but within 30 minutes or so, it would crash.  So I did a fresh install from the last official build I had saved from June 2023:

> Armbian_23.5.2_Nanopineo_bookworm_current_6.1.30

Dear @dave3
I had the same problem with my three NanoPi Neo2 (the H5 version of the Neo)
I went for the (latest) 6.1.36 image and did also the freeze kernel/firmware (now they are running cool/stabe:

That's good to know.  I haven't installed the later 6.1.47 version.  I've still got the kernel frozen at 6.1.30 and it's running fine.  Maybe the slightly older official version is better than the latest.

 

I've thought about trying to upgrade to the latest community build, since it's been some time, hoping they've fixed it, but I'm hesitant.

I had several problems updating the nanopi neo.
After kernel update no boot. unfortunately i have to the cable to connect to uart...
Last week i decided to flash a new image from the website.
But same problem no boot...
So i started to do tests on the previous image...
Everytime that the initrd became bigger than 12mb... no boot...
I found a fix:
sudo nano /boot/boot.cmd
after the line
setenv load_addr "0x44000000"
i added
setenv ramdisk_addr_r "0x45000000"
save the file and
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

i was able to update the latest kernel and then also update bookworm to trixie...
today i want to do some tests with official image to see if the problem was the same...
but i cannot find the image anymore..
Was removed?

For what its worth, I switched my NanoPi Neo to DietPi. It also uses the armbian kernel, but I found it better supported.

 

Linux nano 6.18.45-current-sunxi #1 SMP Wed Aug 19 16:18:21 UTC 2026 armv7l GNU/Linux

 

There was something like you mentioned with the load_addr they fixed last year.

 

https://github.com/MichaIng/DietPi/issues/7557

7 hours ago, Lamerjack said:

today i want to do some tests with official image to see if the problem was the same...
but i cannot find the image anymore..
Was removed?

There is indeed no nanopineo image on the main download page. I remember there was only rolling release, maybe image creation failed so then I think automatically not there/visible.

The build definition is there: https://github.com/armbian/build/blob/main/config/boards/nanopineo.csc

 

But if you just need the original or an original boot.cmd (so some version), it is in the BSP:

armbian-bsp-cli-nanopineo-current/trixie,now 26.8.3 armhf [installed]

# dpkg -L armbian-bsp-cli-nanopineo-current | grep boot.cmd
/usr/share/armbian/boot.cmd
 

Edited September 19Sep 19 by eselarm

On 9/19/2026 at 11:53 AM, dave3 said:

but I found it better supported.

 

From a technical perspective, Armbian community-supported and DietPi are pretty much the same thing: same kernel source, same U-Boot, same patches. The difference is mainly who answers the issues. 

 

It's a division of labour. Armbian maintains expensive SW stack: the kernel, U-Boot and board support for 200+ boards, and that's where most of our time goes. DietPi only ships that work, which leaves them more time for dealing with users. Their contributions to the shared stack, don't show up in our statistics. A single average Armbian contributor commits more value than the whole DietPi team. That's not a complaint, just how it is.

 

When something on the NEO breaks with a new kernel and later starts working again (Ethernet, Wi-Fi, LEDs, booting itself), that fix usually comes from people you never talk to. They're digging through kernel patches and U-Boot, reading not answering forum posts or GitHub issues. Its open source and anyone use those fixes. If you want to help keep the NEO in good shape, support developers unlike support service.

 

tl;dr on why the two projects don't get along: on these boards, DietPi's kernel, U-Boot and firmware come from Armbian — the same sources and patches, built with our framework. DietPi adds its own userland on top. When something breaks in that stack, DietPi's answer to their users is "that's an Armbian problem". That puts the pressure and the load on us, and leaves their users thinking we're the problem. And it's not a one-off, it happens again and again.

The real problem is the enormous technical complexity of supporting this hardware, which we don't have the resources to keep up with. Dismissing our work doesn't help with that. It makes it worse.