Force/limit core version during pakfire upgrade

O boy that was of course a typo I did not mean ipcop at all. It is all about ipfire of course!

Sorry, for this inconvenience.

But back to the topic: maybe an other pakfire (stable, unstable, testing and “old core”) channel would do the job?

Greetz

3 Likes

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.

2 Likes

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…

1 Like

The testing could be done with ease.

Greetz

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.

4 Likes

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.

3 Likes

Sadly nothing happend here. Sorry, maybe this has a low priority to the dev team. But i still think another “update channel” would be nice.

Greetz

1 Like

I wanted to test Arne’s suggestion works,

so I edited the file
/opt/pakfire/db/lists/core-list.db

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

$core_release="179";
-----BEGIN PGP SIGNATURE-----

and it stopped reminding me to upgrade :slight_smile:

Pretty simple :+1:

That is 100% true, you will not be able to install or update addons. But I still like how simple it is to edit

1 Like

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 :wink:
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.

1 Like

Good topic. :wink:
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.

2 Likes

See this wiki page about why the IPFire devs do not recommend using IPFire in a virtual environment for any production situation.

Be aware of the security risks and the potential performance impacts.

https://www.ipfire.org/docs/hardware/virtual

2 Likes
Virtual environments have many disadvantages
when used with IPFire.
...
Therefore it is not recommended 
to use IPFire in production in
such a virtual environment.

:man_facepalming:

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 :man_shrugging:

btw:
i am a fan of the idea to go to a defined core version :bulb:
the brand-new version is by no means the better version!

1 Like

I would prefer too an option to update to a defined core version as the auto update to the latest.

2 Likes

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.

Not the most elegant but it works!

1 Like

@jon
really :question: :man_shrugging:

the core-upgrades are stored:
https://mirror1.ipfire.org/pakfire2/2.29.2-x86_64/paks/

Try:
https://mirror1.ipfire.org//releases/ipfire-2.x/

Not an option for me. I have a limited physical access to my firewalls.

2 Likes

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.

1 Like