Bullseye Image for Odroid N2

Hi. I need the Bullseye image for Odroid N2 for compatibility reasons with specific software.

Unfortunately the image for Odroid is no longer available under downloads (only other hardware).

Can anyone help out and provide the image?

Filename should be something like DietPi_OdroidN2-ARMv8-Bullseye.img.xz

That would help me a lot!

There is no image available because we stop supporting bullseye. Trixie is out and we will support the last version (bookworm) until the next debian release.
https://dietpi.com/downloads/images/

Some users reported that they were able to find older images via archive.org / waybackmachine

edit: here you go https://web.archive.org/web/20220703165704/https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Bullseye.7z

1 Like

At least the DietPi scripts will support Bullseye until the end of this year, 2025. Most likely, script support will be discontinued in DietPi v10.

pls keep the nanopi 2 and 3 alive if possible :smiling_face_with_tear: i need them

you can continue using them, but Bullseye systems will not receive the update for DietPi v10.

This is unrelated to Debian package updates for Bullseye.

The Debian 11 life cycle encompasses five years: the initial three years of full Debian support, until August 14th, 2024, and two years of Long Term Support (LTS), until August 31st, 2026. The set of supported architectures is limited during the Bullseye LTS term to i386, amd64, armhf and arm64. For more information, please refer to the Security Information webpage and the LTS section of the Debian Wiki.

See Debian -- Debian “bullseye” Release Information

Sorry, will be dropped with DietPi v10 at the beginning of 2026. We will migrate Bullseye systems to a dedicated branch with that DietPi update, so systems will continue to run, and might get selected updates, but we will remove images from our download page and server, and support for those.

Do not use those for any remotely sensitive task anymore. The kernels are hopelessly outdated, especially for the NanoPi 2 family, but also Linux 4.14 even upstream did not receive any patches since 2 years. And the kernel source which was maintained years ago by Armbian is Linux 4.14.180 from 5 years ago. It does not provide all features for recent Debian versions to work well, and Debian Bullseye is also EOL, and looses LTS as well next year.

But I agree with you that it is very sad, that these Samsung SoCs never got any mainline Linux support. Also rebasing the vendor sources onto newer Linux versions seems to have been enough pain for no one to do, aside of Armbian with s5p6818 until efforts became too large. I have a NanoPi Fire3 here, and it is still crazy fast, faster than RK3399 SBCs with 8 vs 6 cores, and that with a form factor close to RPi Zero.

@cdanne
I know it is not possible in every case, but I highly recommend to push developers/maintainers of whichever software you use to support recent platforms/environments. If something does not support Debian Bookworm now, over 26 months after its release, or Python 3.11, PHP 8.2, …, I tend to say it is most likely not secure to use anyway.

2 Likes

yes the s5p6818 is fast! and I’ve got 8 nanopi fire 3 built for cluster computing but still not able to properly configure them with K3s installed by dietpi…. there are several bugs found for K3s but I believe I should open separate topic for that when I have time…..

Hope I can get the k3s up and running before they are dropped by dietpi…

you can continue running DietPi. It’s not going to stop. You just won’t receive further DietPi updates.

thanks for the clarification.

I’ve indeed updated all of the images to bookworm recently.

Although the discussion moved on, I just wanted to say thank you esp. @Jappe for you help with my original request!

The link helped a lot and I managed to set up a system with Bullseye again. Perfect, thanks!

1 Like

With such an old kernel, this AFAIK is not possible with any recent container engine versions. The same problem appeared with the Sparky SBC and NanoPi 2 series at some point, when container engines started to require kernel features from Linux 5.x.

Skip it if this is about NanoPi 3 only, this most likely cannot be fixed, and I won’t waste my time trying to fiddle with these old kernel sources. But if you found issues with K3s on Linux 6.1 and above, please let us know.

Don’t go higher. Already on Bookworm some things won’t work, e.g. WiFi should be mostly broken, as the kernel is not able to read allowed frequency bands from the regulatory database, falling back to some very limited global WiFi channels/frequency bands.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.