end of the road for oxnas?

It looks like OpenWrt is dropping oxnas after the upstream community has discontinued support. Is this the end of the road for oxnas?

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6ca830559865f994db8732a9d06f452e36d5b490

@Koen,

> It looks like OpenWrt is dropping oxnas after the
> upstream community has discontinued support. Is
> this the end of the road for oxnas?
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6ca830559865f994db8732a9d06f452e36d5b490

We are at 5.4.x here. So it will be tracked to 5.4 LTS until Dec, 2025. Yes, it will be the end of the road for OXNAS on Dec 2025.

Quote
https://www.kernel.org/category/releases.html

Version Maintainer Released Projected EOL
5.4 Greg Kroah-Hartman & Sasha Levin 2019-11-24 Dec, 2025

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Makes me sad for both of my Pogoplug Pro's as they have run Pi-hole and Time Machine backups so well for the past 12 or so years.

I remember buying a bricked Shuttle KD20 NAS years ago and finding the forum when I was trying to unbrick it. It started my 'hobby' of buying cheap electronic devices on ebay and taking them apart trying to understand how they work.

We are also facing another EOL issue with a possible removal of armel architecture in Debian 13. Basically, if that happens we can continue upgrading Kirkwood kernel, but all Kirkwood boxes are stuck in Debian 12 :( Hopefully another distro will still support armel.

What has kept armel in Debian 12 is the rPi, thanks rPI :) I hope that specific rPI board will continue to ship for a longer time.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/25/2024 02:56PM by bodhi.

Koen Wrote:
-------------------------------------------------------
> I remember buying a bricked Shuttle KD20 NAS years
> ago and finding the forum when I was trying to
> unbrick it. It started my 'hobby' of buying cheap
> electronic devices on ebay and taking them apart
> trying to understand how they work.


@Koen so well said! I have developed the same hobby and thanks to this website was able to vastly expand my skills.

Looks like we are still OK for Kirwood ans OXNAS boxes in Debian 13

https://www.debian.org/releases/trixie/release-notes/whats-new.en.html

Quote

2.1. Supported architectures

The following are the officially supported architectures for Debian 13:

32-bit PC (i386) and 64-bit PC (amd64)
64-bit ARM (arm64)
ARM EABI (armel)
ARMv7 (EABI hard-float ABI, armhf)
little-endian MIPS (mipsel)
64-bit little-endian MIPS (mips64el)
64-bit little-endian PowerPC (ppc64el)
IBM System z (s390x)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Looks like we are still OK for Kirwood ans OXNAS
> boxes in Debian 13
>
> https://www.debian.org/releases/trixie/release-notes/whats-new.en.html
>
>

Quote

2.1. Supported architectures
>
> The following are the officially supported
> architectures for Debian 13:
>
> 32-bit PC (i386) and 64-bit PC (amd64)
> 64-bit ARM (arm64)
> ARM EABI (armel)
> ARMv7 (EABI hard-float ABI, armhf)
> little-endian MIPS (mipsel)
> 64-bit little-endian MIPS (mips64el)
> 64-bit little-endian PowerPC (ppc64el)
> IBM System z (s390x)

Excellent news, thanks for the update!

bodhi Wrote:
-------------------------------------------------------
> We are also facing another EOL issue with a
> possible removal of armel architecture in Debian
> 13. Basically, if that happens we can continue
> upgrading Kirkwood kernel, but all Kirkwood boxes
> are stuck in Debian 12 :( Hopefully another distro
> will still support armel.

Don't mean to revive an old thread like this, but when Debian drops armel eventually as an official port, it'll (likely) move to unofficial status, meaning that just like sparc64, which went to unofficial around 6 years ago, ISOs/etc as with all the other unofficial ports will still be built, on an unofficial basis and packages will still be built and available as they're able to be built... anything else would need to be manually compiled and supported by the end user.

it just means that the doozan forums will be the only place to get a clean working copy of an OS for certain devices, albeit with more chances for the system to be rather unstable.

It would also make sense, while it exists, to get a Gentoo rootfs made as an alternative as Gentoo is the only other distro at the moment supporting armel after Arch dropped support. A friend of mine is running Gentoo on his KACE and it works a treat, albeit a bit fiddly when it comes time to do a full system upgrade, but it still manages to come out in the end in one piece. it would definitely be more work and would probably be limited to use for only the systems with more RAM due to the necessity to compile quite a bit... but at least some armel devices might make it to 2030 with normal use. so yeah. possibly an idea there.

> it just means that the doozan forums will be the
> only place to get a clean working copy of an OS
> for certain devices, albeit with more chances for
> the system to be rather unstable.

I think we'll cross that bridge when the time comes.

> It would also make sense, while it exists, to get
> a Gentoo rootfs made as an alternative as Gentoo
> is the only other distro at the moment supporting
> armel after Arch dropped support.

It might come to that. But I hope the old rPi boards will be shipping for a while, and that's a pretty good reason for Debian to keep maintaining armel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Got a Rpi 0w and a free 128GB Microcenter micro SD card today for $7.99+ tax.

FWIW I've started putting together Buildroot configurations and tools for Buffalo devices as an alternative to Debian. Originally I focused on the newer devices using SoCs without sufficient mainline support (RealTek RTD1619, RealTek RTD1195N and Alpine AL-314) and have now started adding profiles for mainline devices as well.

For the non-mainline devices it's an exercise in making the most of what I can accomplish with the GPL kernel source provided by the manufacturer. The results were better than I anticipated, it turns out most applications will build/run just fine against an old 3.10.x kernel. Between compiling applications as part of the Buildroot process and Docker I've been able to run just about anything I can think of.

For the older mainline devices it's allowed me to generate a smaller/lighter OS which runs noticeably better than a default Debian install (Admittedly, I've never put much work in optimizing Debian installs on these devices). I recently tested it out on an old Orion5x device with 128mb ram and was surprised how well it worked.

It seems like Buildroot is a decent alternative for some of these devices if/when Debian support becomes untenable. It's been a few years since I messed with Gentoo, last I knew trying to cross-compile a whole system was.... aggravating.