Plugins will not install any more — the installer says the base release was not found. Is the plugin system broken or gone?

It is the second thing, and the error is more honest than it looks.

How the plugin system works underneath. A plugin is not a self-contained package. It is a lightweight isolated environment built from a base release of the underlying operating system, into which the plugin's software is then installed. The plugin catalogue records which base release each plugin was built against, and the installer's first move is to fetch that base release from the vendor's mirror.

So the failure is happening at step one: the installer asked the mirror for a specific release and the mirror said it does not have it. Which is correct — that release reached end of life and was removed from the distribution mirrors. Nothing is misconfigured on your machine.

Why your existing plugins are unaffected. They already have their base environment on disk. They never ask the mirror for anything again unless you update them. This is exactly the situation where things look fine right up until you touch them, and it is why the first new install after a long gap is what surfaces it.

Why the major upgrade is relevant. After a major version change, the plugin catalogue on your machine is often still the old one, pinned to the old base release. Meanwhile the whole plugin and jail subsystem has been progressively deprecated in favour of containers, so the catalogue is not being maintained forward either. You are looking at a subsystem in wind-down, and the missing release is a symptom rather than the disease.

What to actually do.

The honest answer is to move the workload to a container. Every service that ever shipped as a plugin has a maintained container image, usually a better-maintained one, and containers are where the platform's attention has gone.

The migration is less painful than it sounds because the plugin's data is on your pool, not inside the plugin. Same principle as any other container migration: find the paths the plugin writes to, stand up the container pointing at those same paths, verify, then remove the plugin. Take a snapshot first.

What not to do: do not go looking for an archived copy of the retired base release to feed the installer. It works, briefly, and you end up running a service on an unpatched base operating system that no longer receives security updates, inside a subsystem that is being removed. That is a worse position than the one you are in now.

One thing you should do soon rather than eventually: your existing plugins are running on that same end-of-life base. If any of them is reachable from outside your network, treat moving it as urgent rather than a project for the winter.

Worth checking which of your plugins actually needs migrating at all.

In my case two of the four were things I had installed years ago, used twice, and forgotten about. The migration project shrank by half the moment I looked at what was genuinely in use rather than what was merely running.

Check the access logs or the last-modified time on each one's data directory before you plan any work for it.

Order of operations for the migration, since the temptation is to do it the fast way and the fast way is the one that loses data.

1. Snapshot the datasets the plugin uses. All of them.
2. Stop the plugin. Do not run the container against live paths while the plugin is also running — two processes writing the same database is how you get a corrupt database rather than a migration.
3. Start the container against the same paths, read-only first if the app supports it, and confirm it sees your data.
4. Switch to read-write, use it for a few days.
5. Only then delete the plugin.

Step four is the one people skip. The plugin costs you nothing sitting there stopped, and it is the cheapest possible rollback.