Which mechanisms to prevent fatal update errors are implemented?

Hi everyone,

I’m pretty new to IPFire and need to maintain one device running that for a customer which is hundreds of kilometers awaqy from my own working location. While I like the Linux base and package management, I’m not convinced about updating the whole system itself yet. During research about that topic, I’ve found quite a few discussions in this forum about devices not booting at all after updates or if they boot, that SSH, the web-UI etc. don’t work anymore. All of those problems are of cause pretty fatal in my case, because those things don’t read like they could be fixed remotely and my customer wouldn’t be able to work at all anymore. So the bottom line currently is that I simply can’t risk updating at all. :-/

Backing up some settings or configs using the web-UI is obviously not sufficient to prevent against those types of errors. At some discussion I read about backing things up entirely using CloneZilla. Though, I don’t understand how to restore such backups e.g. when the device simply doesn’t boot at all anymore. Currently I’m backing up the entire device using RSYNC already. So, I’m wandering if there’s something I’m missing currently…

Do the updates don’t implement some A/B mechanism using multiple partitions, so that in case of boot problems the old partition could simply be booted?

Or is there some kind of snapshots integrated using e.g. BTRFS, maybe as some optional installation method? My device seems to use EXT4 only, though, lots of NAS with only minor processing power use BTRFS as well these days.

Is there some rescue system or alike automatically booting in case of other boot or remote management failures? Maybe something which needs to be setup optionally using PXE and TFTP or something like that?

Or is there really nothing and if some update breaks remote access for any reason one simply is doomed?

Thanks!

1 Like

This is what I have done for a number of years and never had an issue:

  1. Run IPfire on a suitably spec’d appliance. Eg: I use Protectlii.

  2. Avoid going under the hood to configure, if at all possible. Do all configuration from WUI.

  3. Have appliance plugged into a reliable power source.

Depending on client/budget and level of redundancy required you could send out a spare IPfire fully configured as a backup.

RS

2 Likes