Bug #11478
closedRestoring a backup on 2.4.5-p1 triggers an incomplete upgrade to 2.5.0
0%
Description
After running in to some regressions on 2.5.0 covered by other bugs on the tracker, I decided to re-install pfSense 2.4.5-p1 and restore the backup I took prior to upgrading to 2.5.0. However, during the configuration restoration process packages are automatically installed. If the firmware branch is set to the latest stable, i.e. 2.5.0, then this will attempt to install packages from 2.5.0 which can be incompatible with 2.4.5-p1. This includes the installation of 'core' packages such as pfSense itself as seen in the logs;
pfSense upgraded: 2.4.5_1 -> 2.5.0
Once this process completes, the user is left with a broken pfSense installation. For example, the WebConfigurator displays the following PHP error on all pages;
PHP ERROR: Type: 64, File: /etc/inc/config.inc, Line: 51, Message: require_once(): Failed opening required 'Net/IPv6.php' (include_path='.:/etc/inc:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/')
and most options on the console (i.e. everything but the shell option) will output the following messages before displaying the option selection menu again;
/etc/rc.initial: /etc/rc.restart_webgui: not found /etc/rc.initial: /etc/rc.banner: not found /etc/rc.initial: /usr/local/sbin/read_global_var: not found
In order to prevent this issue, when a backup restoration is triggered the package repo used should be set to the current installed version - which may no longer be 'stable'. Currently, if a user selects a different firmware branch prior to restoration, or sets the pkg_repo_conf_path setting to the desired version in the backup file, the restoration process will reset the firmware branch back to the default one prior to installing packages. This is likely the intended behaviour when installing an older backup on to a newer system to prevent old packages from being installed on the newer system (e.g. when restoring a 2.3.0 backup on 2.4.5). However, as the default branch for 2.4.5-p1 now points to 2.5.0 packages this results in 2.5.0 packages being installed on a 2.4.5-p1 system.
To work around this issue, as suggested by stephenw10 on this forum thread the WAN connection should be disconnected when restoring the backup. This restores the configuration, but prevents the packages from being installed. Once the package installation process has timed out (33 minutes after boot in my case), the WAN connection can then be reconnected. This will allow pfSense to check for an updated system version, and for the firmware branch to be switched from the 2.5.0 stable branch to the 2.4.5-p1 deprecated branch. Once complete, compatible packages can be installed from the package manager without triggering an incomplete upgrade to 2.5.0. No reconfiguration of the settings of the installed packages is necessary, as this is contained within the backup.
I have set the Affected Version for this bug to All - although I have specifically encountered it on 2.4.5-p1, I can foresee this issue also affecting any installation where the 'stable' firmware branch is ahead of the current installed version at the time of performing a backup restoration. At the moment, this issue would prevent someone with a 2.4.5-p1 installation from performing disaster recovery via backup restoration unless 2.5.0 was compatible/stable with their use case, or they were aware of the WAN disconnection workaround.