Upgrade pfsense CE 2.7.0 to 2.7.1
-
@SteveITS said in Upgrade pfsense CE 2.7.0 to 2.7.1:
@stephenkwabena
https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting
“Due to changes in pkg, the new version of pkg may not be able to properly locate and use the CA trust store when running on the previous version before upgrading.If the firewall is unable to load packages or check for updates after selecting the CE 2.7.1 upgrade branch, run certctl rehash from the console, a root shell prompt, or via Diagnostics > Command Prompt. This will allow pkg to utilize the system certificates until the next reboot.”
Thanks...this worked
-
@ersterhernd I guess I'll do the same. No internet after upgrading to 2.7.1-ce (3.5 hrs upgrade time). I reverted back to 2.7.0.
-
@coldfire7 were you using VLANs or anything? For some reason I had no internet access or GUI access after trying to restore a Plus 23.05.1 backup to either 2.7.0 or 2.7.1 configuration.
However whenever I at least completed the basic setup to return the base LAN to it's original IP range, as opposed to the 192.168.1.X defaults, then that segment of the network began working. Unfortunately my VLAN for IoT is not working at all though so I'm going to have to redo my network I fear from the Plus to CE migration conflicts.
-
-
@Zaf9670 No VLAN, but I have multiple WANs and I can access the GUI.
-
I had error, too.
i had a message in frontend: update available. installed and rebooted.
after this, version was still 2.7.0 and repo was 2.7.1 under update.
Update check allays says (repo 2.70 and 2.71) i am up to date and 2.7.0 is installed
after this i have looked into packages available --> no packages.I have found post, i should run
pkg update
elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
pkg-static:
An error occured while fetching package
searched for the errors and i runpkg-static bootstrap -f
Installed a newer version than kernel
after thispfSense-upgrade -d
runs the update to 2.7.1 with success. now packages are available to.
Seems to be a broken update routine. no other error occurs
-
This post is deleted! -
None of my secondary HA machines can see the update and rehashing the certificates doesn't help.
I am wondering if it has something to do with my policy routing? So what is the URL for the update server so I can run a test with my alias list? I suppose I can just temporarily disable the policy routing rule on my secondary server, but to fix the problem I would need that URL. ... I just realized that it would have to be done on my primary server I think.
-
@stephenkwabena said in Upgrade pfsense CE 2.7.0 to 2.7.1:
certctl rehash
This worked for us. Thank you.
-
@SteveITS said in Upgrade pfsense CE 2.7.0 to 2.7.1:
@stephenkwabena
https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting
“Due to changes in pkg, the new version of pkg may not be able to properly locate and use the CA trust store when running on the previous version before upgrading.If the firewall is unable to load packages or check for updates after selecting the CE 2.7.1 upgrade branch, run certctl rehash from the console, a root shell prompt, or via Diagnostics > Command Prompt. This will allow pkg to utilize the system certificates until the next reboot.”
Monday Afternoon I noticed another "Wrinkle" within my attempts for at upgrading/package installs (within various pfSense CE/Plus Instances, both Real and Virtual):
Attempts to upgrade pkg-1.20.8_1 to pkg-1.20.8_2 were FAILING!!!Later in the Day Netgate released pkg-1.20.8_3, which appears to have "Fixed" this "CA trust store" Issue???
Now I find CE 2.7.0 is NOT as "Useful", without running running "certctl rehash" from the console, a root shell prompt, or via Diagnostics > Command Prompt: Otherwise Access to Updates and/or Packages are NOT be possible (even though pfSense might still be running well)!!! NOTE: "certctl rehash" is "Temporary" and has to run following a Boot/Reboot!!!
Therefore running "certctl rehash" (if required) and upgrading CE 2.7.0 to CE 2.7.1 might be the "Better" Option???
-
This post is deleted! -
@LHoust said in Upgrade pfsense CE 2.7.0 to 2.7.1:
Now I find CE 2.7.0 is NOT as "Useful", without running running "certctl rehash" from the console, a root shell prompt, or via Diagnostics > Command Prompt: Otherwise Access to Updates and/or Packages are NOT be possible (even though pfSense might still be running well)!!! NOTE: "certctl rehash" is "Temporary" and has to run following a Boot/Reboot!!!
If you want to remain on 2.7.0 and have pulled in the newer pkg version you will need to set the repo back to 2.7.0 then rehash the certs and force upgrade pkg back to the version from that:
1.19.1_2
.Then you should be able to pull in other pkgs and will not need to rehash certs again.
-
@reberhar I was able to do the updates by putting the primary server on standby and, when the secondary server was acting as primary server, I could do and did updates to these units as well.
I did make the mistake of trying to do updates of packages from the package manager without doing the system update first, notably NUT. I did set the system back to 2.7.0 to fix that. All the package updates came with the system update, again, including the NUT 2.8.2, which I wanted because of problems with NUT and Cyberpower. It is early, but things seem better now.
-
If only the primary nodes can see the package servers that's often a sign that the outbound NAT rules are over-matching and translating traffic from the firewall itself to the CARP VIP. That breaks connectivity for the the backup node.
-
@stephenw10 Thanks ... I suspect that it is a firewall rule. That I am sending the firewall to the Virtual IPs is possible I suppose. I do have an aliases with both lan numbers, primary and secondary, so that I can access the secondary via the tunnels. I will study them to see what the impact is. The outbound NAT is a very busy place for my systems.
Thanks for pointing me in toward the likely direction of the problem.
Interestly I did not have this problem before 2.7.0, thus my thought that it does have to do with the firewall and the more strict enforcement of the rules.
I may have found it. The translation address is the virtual IP. This would do as you say. Then only the primary node can receive the update messages.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to the -
I updated with no issues
-
I just tried second time and no way. I had home router based on Intel NUC + USB NIC as a WAN. This was worked on 23.05+ and also on 2.7.0 that I migrated to. When I try upgrade to 2.7.1, upgrade goes without issue, NUC will reboot and start. Unfortunately it seems like there is problem... pFsense hangs after while. It is not fully hang, but I do not have possibility to login to GUI, there is "502 Bad gateway" message. No packages get installed, interfaces ar enot working correctly.. I didnt find solution yet how to get it working.
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ? Seems like a lot of changes in "minor" update was done , it should not be 2.7.1, but 2.8.0...
-
@reberhar said in Upgrade pfsense CE 2.7.0 to 2.7.1:
I may have found it. The translation address is the virtual IP. This would do as you say. Then only the primary node can receive the update messages.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to theUsually when we see this the rule has a source of 'any' which is almost always wrong.
-
@GeorgeCZ58 said in Upgrade pfsense CE 2.7.0 to 2.7.1:
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ?
Did you try installing 2.7.1 clean?
-
@GeorgeCZ58 said in Upgrade pfsense CE 2.7.0 to 2.7.1:
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ? Seems like a lot of changes in "minor" update was done , it should not be 2.7.1, but 2.8.0...
In my own testing with a Fresh Installation of CE 2.7.0 within a VM: I was able to confirm what stephenw10 mentioned:
If you want to remain on 2.7.0 and have pulled in the newer pkg version you will need to set the repo back to 2.7.0 then rehash the certs and force upgrade pkg back to the version from that: 1.19.1_2.
Then you should be able to pull in other pkgs and will not need to rehash certs again.
The Day following CE 2.7.1's Announcement, there were already some System Patches, therefore if you are able to install the "System_Patches" Package and apply them (and Reboot), some of those Patches might apply to this case with your Intel NUC?
Last week with CE 2.7.0 (before I knew about having to rehash the certs following every Boot/reBoot or downgrading to pkg-1.19.1_2), a Fresh Installation of CE 2.7.1 is what had worked for me with my ZimaBoard.
-
@stephenw10 I will try. So practicaly I will do the same, but will not apply old config... we will see.