Re: How to upgrade an EOL FreeBSD release or how to make it working again

On 15 Jan 2024, at 16:46, Mario Marietto <marietto2008@gmail.com> wrote:
> 
> The ARM Chromebook is based on armv7,it is still recent.

For reference, the ARMv7 architecture was introduced in 2005.  The last cores that implemented the architecture were released in 2014.  This is not a ‘recent’ architecture, it’s one that’s 19 years old and has been largely dead for several years.

> But let's change perspective for a moment,don't think about the ARM Chromebook. My question is : how to upgrade FreeBSD when it goes EOL.

Generally, run `freebsd-update`.  This is a very different question from ‘how do I do a new install of an old an unsupported version?'

> I ask this because there is a huge difference here between FreeBSD and Linux. Today if you need to use , for example Ubuntu 14.0, you can use it as is. Yes,there will be a lot of bugs,but it will work without crashes.  But if you want to use an old FreeBSD system,nothing will work for you. So,do you know some methods to install even packages or ports ? You know,there are cases when you need to do some experiments so that you can keep your machine off the internet,so you aren't scared that someone can compromise it. Totally prohibiting the users to use an old system,removing ports and packages is not a choice that I approve of. And I'm not the only one that thinks like this.

If you want to use an old and unsupported version of FreeBSD, no one is stopping you, but:

 - You will need to build the releases.  The source code is still in git, you can.  The scripts for building the release images are right there in the repo.  Just grab the relevant release or releng branch and go.

 - You will need to build packages.  Newer versions of the ports tree will not be tested with the older release, so you may need to use an older checkout of the ports tree.  Poudriere will build a package repo for you.  

In both cases, if you’re using older versions you almost certainly *will* have security vulnerabilities.  The project strongly advises you not to do this and not to blame us when you install known-insecure software and end up compromised.

The project does not have enough active contributors to keep maintaining things indefinitely.  This is why release have a five-year supported lifetime.  If you want to pick up an old branch and maintain it, you’re welcome to.  In the past, companies have picked up old branches and maintained them for customers that had a dependency on them.  If you want to pay someone to maintain an old branch (and have deep pockets) then there are probably a few companies that will happily take your money.

Maintaining binaries is a slightly different issue, but it’s not totally unrelated.  Keeping old packages around consumes disk space and costs the project money (remember, every package is mirrored across the CDN, so this isn’t just a single disk).  Even if it were free, philosophically, I think making it easy for users to install known-insecure software is a bad idea but if you want to keep a package repo with out-of-date packages online indefinitely then you can.  You can run Poudriere and even cross-compile from a fairly beefy cloud machine quite easily.

It’s been a while since I did a full package build, but I would guess that you could do a single package build (all ports) for about $50 on a cloud VM, more (2-3x) if it’s emulated.  Storing the results for a small number of users will cost around $10-20/month.  If you think this is an important thing to do, then you are absolutely welcome to spend your own money on doing it.

David