Updates not going well
-
I installed 2.5 and restored the config. It appears all went well (so far
).Is it my imagination or does ZFS boot faster?
-
@jknott said in Updates not going well:
Is it my imagination or does ZFS boot faster?
I think it's 2.5. I was on ZFS before and 2.5 seems much faster even on my under-powered VM..
-
ZFS is more resilient. If you have pfSense installed somewhere that power cannot be guaranteed it's definitely worth considering.
Boot times for pfSense really shouldn't be an issue IMO. If you're rebooting it that often you're probably doing it wrong.Steve
-
I have mine on UPS & run apcupsd so it will shut down properly on power failure.
-
Then, you're unlikely to see an issue remaining on UFS.
There are some other things in ZFS that are nice to have like snapshots. Until support for that is in the gui though actually using that isn't that straight forward.
Steve
-
@stephenw10 said in Updates not going well:
If you're rebooting it that often you're probably doing it wrong
QFT!
-
@stephenw10 said in Updates not going well:
You should install 2.4.4 then update to 2.5 then restore the config.
If you restore the config into 2.4.4 without first setting the pkg repo to the correct brancg it may pull in invalid packages.
It would be better to just get a 2.5 image and install as ZFS dircetly. Then restore the config.
Steve
Thanx for the 2.5 version.
I have a few questions regarding restoring to 2.4.5-p1 (if sh.. hits the fan).
I have changed my update repos to the Deprecated 2.4.5-p1 repos , and saved the config.
So if i want to fallbck to 2.4.5-p1 , after upgrading to 2.5.01:
I just install the 2.4.5-p1 image (it will point to default repos - 2.5.0) , but install no packages, due to a "factory config"2:
I'll connect to the LAN , and upload my saved 2.4.5-p1 config , that points to the Deprecated 2.4.5-p1 repos.3:
pfSense will now reboot , and install the packages in my saved config, from the Deprecated 2.4.5-p1 repos.Is that the way to do it ??
TIA
/BingoFor others searching for the 2.4.5-p1 images:
2.4.5-p1 archive - SHA sums + Win10 Sha tip
Memstick - Serial SHA256 Checksum for compressed (.gz) file: 9ce90667f39f837df88e936aa0fd478c2aee8f96a8b8d54d13431a921e877cac ********** Memstick - VGA SHA256 Checksum for compressed (.gz) file: aa40595d090465f20fff1890092e6a14a753cd9486ccc7101d81301cad8b8840 ********** Calc SHA on Win10 C:\pfsense\2.4.5-p1>certutil -hashfile pfSense-CE-memstick-serial-2.4.5-RELEASE-p1-amd64.img.gz SHA256 SHA256 hash of pfSense-CE-memstick-serial-2.4.5-RELEASE-p1-amd64.img.gz: 9ce90667f39f837df88e936aa0fd478c2aee8f96a8b8d54d13431a921e877cac CertUtil: -hashfile command completed successfully. -
Yes, that will probably work. It will complain about restoring a 2.5 config into 2.4.5 though.
If you can you should use a config saved from 2.4.5 to ensure compatibility.
Steve
-
@bingo600 said in Updates not going well:
So if i want to fallbck to 2.4.5-p1 , after upgrading to 2.5.0
1:
I just install the 2.4.5-p1 image (it will point to default repos - 2.5.0) , but install no packages, due to a "factory config"
2:
I'll connect to the LAN , and upload my saved 2.4.5-p1 config , that points to the Deprecated 2.4.5-p1 repos.
3:
pfSense will now reboot , and install the packages in my saved config, from the Deprecated 2.4.5-p1 repos.Unfortunately, i've tried this method without much luck - and that's with restoring an actual 2.4.5-p1 config.
I performed a fresh install of 2.4.5-p1 and then updated
pkg_repo_conf_pathin my 2.4.5-p1 config backup to point to/usr/local/share/pfSense/pkg/repos/pfSense-repo-245.confrather than/usr/local/share/pfSense/pkg/repos/pfSense-repo.confso that 2.4.5 compatible packages would be installed. However, as part of the config restoration pfSense will change the package repo back to the default repo if the repo specified in the backup is different. Thus, the package configuration for 2.5.0 is used which results in several breaking packages being installed on 2.4.5-p1 - including 2.5.0 itself! This ultimately breaks the Webconfigurator with the following error message;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/')Most options on the CLI also cease to work, and return 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 foundUnless there's any further workarounds to allow for a backup restoration on 2.4.5-p1 to use the 2.4.5 package repo configuration, my next approach is going to be to selectively restore all but the package-related parts of the backup and then re-do the package installations and configurations by hand.
-
Hmm, the package configs will be retained even if the packages themselves are not installed.
So, you could install 2.4.5p1 clean then restore your config file with no WAN connection.
That will take a while since there is a bunch of stuff that needs to time out. You will end up with the config installed in 2.4.5p1 without the packages.
Re-connect the WAN so the repo list is updated and select 2.4.5-deprecated. Then install the packages you need and the package config will all still be there.Steve
-
@maverickws said in Updates not going well:
Honestly I don't grasp why people insist on ZFS (that actually consumes a lot of resources) for a router. Just another hype.
"Copy on Write" aka CoW is why. For my bigger sites I have ESXi infrastructure and run PFsense virtualised. For the remote sattelite sites I have hardware table-top firewalls. I used to have UFS and had to have an inordinate amount of truck rolls to replace non-functioning firewalls. It would usually be after a power outage or if someone goes "internet is down let's try turning the wall cabinet power switch off and on".
Sudden loss of power can corrupt UFS - sometimes irretrievably. Since reinstalling all the hardware boxes to ZFS we've had no such problems. We do tell the staff to not blindly turn off networking equipment but they don't always comply.
So my mantra now is UFS on all cloud installs and ZFS on all hardware installs, and my life is much better for it.
-
Here is what happens if you change the System -> Update to the 2.4.5-p1 Deprecated repos. (A config diff) , from when i changed to the 2.4.5-p1 repos.
+++ /conf/config.xml 2021-02-18 21:35:57.428044000 +0100 @@ -180,7 +180,7 @@ <repositoryurl></repositoryurl> <branch></branch> </gitsync> - <pkg_repo_conf_path>/usr/local/share/pfSense/pkg/repos/pfSense-repo.conf</pkg_repo_conf_path> + <pkg_repo_conf_path>/usr/local/share/pfSense/pkg/repos/pfSense-repo-245.conf</pkg_repo_conf_path> <ssh>Here is what is in the git "snip" you pointed at.
/* * Configure default pkg repo for current version instead of * using it from backup, that could be older */ $default_repo = pkg_get_default_repo(); $current_repo_path = ""; if (!empty($config['system']['pkg_repo_conf_path'])) { $current_repo_path = $config['system']['pkg_repo_conf_path']; } if ($current_repo_path != $default_repo['path']) { $config['system']['pkg_repo_conf_path'] = $default_repo['path']; write_config( "Configured default pkg repo after restore"); pkg_switch_repo($default_repo['path']); }I don't know the inners of pfSense enough to be able to say what happens here.
I think the first "git" block actually checks if it was booted on a "factory config", and if not. Sets the repos , read from the config.
But in the 2'nd block - It could seem like it overwrites the "custom / non-default repos" with the default repos. Why ???
But again this is a guess from my side , because what does defaut repos point at , if we have installed a 2.4.5-p1.
One thing i noticed in your description.
You write you installed a "clean" 2.4.5-p1 , and changed the repos to 2.4.5-p1 Deprecated. What about the config restore ??
Did you change the repos in that file too ?.I have made a 2.4.5-p1 config backup after i changed the repos to the "deprecated 2.4.5-p1" , that way i had hoped the "old" repos would be used when restoring the old config , on a blank 2.4.5-p1.
But i guess it all might depend on what the "git snip" is doing.
The suggestion @stephenw10 adds , could work.
Restore config wo. Wan , and boot.
Now the system ought to think it's not in restore mode anymore.
And you could change the repos to the deprecated.Below might be a hint for speding up the pkg-install wait ....
https://forum.netgate.com/topic/119298/please-wait-while-the-update-system-initializes/13 killall -9 pkg-static then manually update install the packages from the package managerBut why would Netgate make a "Bill G" on us , in forcing our "in config" selected repos to be set to their "I know better" default repos , that doesn't even correspond to the OS base installed.
If this is the intended behaviour , then there must be a reason for netgate to do so. But it makes fallback harder.
Edit:
Maybe check the BASE OS ver , and see if it matches the "Custom repos", before forcing the defaut repos. Or might be easier "If base os is latest .. set repos to default , else keep the custom repos"/Bingo
-
@bingo600
It's also missing a human check.
If the System > Package Manager > Installed Packages tab was displaying the current Firmware Branch most users would have notice the change.
With a link to System > Update > System Update, most would take time to check some settings before clicking on update package. -
@stephenw10 said in Updates not going well:
Hmm, the package configs will be retained even if the packages themselves are not installed.
So, you could install 2.4.5p1 clean then restore your config file with no WAN connection.
That will take a while since there is a bunch of stuff that needs to time out. You will end up with the config installed in 2.4.5p1 without the packages.
Re-connect the WAN so the repo list is updated and select 2.4.5-deprecated. Then install the packages you need and the package config will all still be there.Steve
I've just given this a try, and it was successful! I now have a 2.4.5-p1 install with functional packages. From first boot to package install timing out took 33 minutes, and this was confirmed by the package install in progress banner disappearing and an alert that the package reinstall process was aborted due to lack of internet connectivity. I plugged my WAN connection back in at this point and switched the firmware update branch to 2.4.5. Before I could switch the branch, two packages were automatically installed;
pkg upgraded: 1.13.2 -> 1.15.6 pfSense-repo upgraded: 2.4.5_2 -> 2.4.5_8This seems fine to me - and likely how my 2.4.5-p1 install was able to recognise that the 'stable' branch is now 2.5.0 and deprecated 2.4.5.
I did have to go through and install my desired packages by hand, but they did indeed retain their configuration from the backup.
Thanks to @bingo600 for the initial idea on how to restore a 2.4.5-p1 backup on 2.4.5-p1, and @stephenw10 for the information on how to work around the package restoration issue! I will file a bug report for this as it does seem like unintentional behaviour - I could see the use case for switching back to the default package branch on restore if an old backup has been restored on to a newer installation, but when restoring a backup on to a non-latest install this shouldn't happen in order to avoid breaking the installation itself through installing packages (including the pfSense base package itself) from a later version.
Edit: Bug #11478 filed.
-
This new version is now working and appears to be stable. I can now use pfBlockerNG without getting frequent Google Chrome certificate errors. And the Amazon app on my phone no longer crashes when pfBlockerNG is enabled. I had some initial issues out of the gate with NordVPN with this new upgrade. However, it was quickly resolved after a clean install of 2.5/ restored 2.4.5 config in 2.5 and unchecked "enable data encryption negotiation." in openvpn. I'm now with glee...Thanks Netgate for this new upgrade!!
