Reverting to a previous state is a very hard problem to solve, see the history of NixOS to have an idea of how challenging is this this apparently simple task. IPFire team is not equipped to solve this problem, therefore it offers the possibility to custom-create an ISO file to reinstall from scratch and then restoring your backup. I think this is your only option, or have a second hard disk cloned and ready to be swapped.
EDIT: reading again your post I believe I misunderstood your suggestion. You want something like a Debian Stable for IPFire, where any update is very stable (and therefore very old). I think @pike_it has already said what would be my opinion in post 14.
This is an interesting idea. If you have a spare device to experiment with it might be worth the effort. My gut tells me it probably won’t work. But it might be worth trying…
Have you been able to force /limit pakfire upgrade to a particular version?
I had a similar idea, I usually check the AWS version of IPFire, and assume it is the most stable version possible. Currently AWS is 184, and newest stable release is 187, testing is 188.
There is a way to do this by editing the lists-file which core is available before run pakfire upgrade but this is a bad idea because installed core and addons need to match.
So if you install an addon that is build against a newer core version (gcc/libs) it may not run so you should always update to the newest core and addons before you install any addon.
This not a good indication. On aws you also should run pakfire upgrade as first action. It is only older because it is much work to update the image to the marketplace.
Although if you’d be able to delay an update, how can you be sure that a special option which is not used often still will work after the delayed update?
…i’m talking with experience in that
I believe in Backups. My solution is to run IPFire (and other sensitive appliances, like NAS, Homeassistant…) as virtual KVM Images. Before i change anything i stop the machine, copy the virtual disk and then do the updates or whatever. If there is any problem it’s very easy to change the disk or even to configure a second appliance and run mutual to compare them.
Good topic.
I’m no friend of virtual instances of a production firewall. But your way could also applied to checking the testing branch of IPFire and giving hints for problems. This would help all of us, IMO.
Virtual environments have many disadvantages
when used with IPFire.
...
Therefore it is not recommended
to use IPFire in production in
such a virtual environment.
virtual environments *can* have many disadvantages
when used the wrong way.
btt:
to me as an ignorant user the core-update looks
incremental. so cant this be modified to install
only ‘one’ next available
btw:
i am a fan of the idea to go to a defined core version
the brand-new version is by no means the better version!
You can always go to https://mirror1.ipfire.org/releases/ipfire-2.x/ and download the version needed (current version is at bottom of the list). You need to restore your IPFire backup from the .ipf file.
I think after the dust clears from Linux evolving its not going to make a difference. Besides older versions are going to have more unrefinements that were existing in the older versions of the web gui.