Upgrade pfsense CE 2.7.0 to 2.7.1

spot33

This post is deleted!

riften

@pfsense2023 Interesting observation on memory... I have always had issues with 'upgrading' and usually swap out my configured ssd with a new one and proceed that way. Apply my backup and watch it not install everything, and have to import my settings a second time to have it actually complete installing all the packages. This is the first time ever that I clicked 'update' and it did it and I didn't have to manually reinstall anything, import my settings again or manually set my NIC/VLAN order. I was using a Qotom with 8gigs ram before, now I have a new box with 16gigs (try and find two 4 gig sticks of sodims that isn't about the same price as 2 8gig sodims these days...). Very possible that it takes more to install and configure than it does to run it.

Smoothest update I ever did... thankfully, as I was running it as an upgrade on my existing 2.7 (felt like living dangerously as I didn't have another NVME handy to swap in.)

coldfire7

@stephenkwabena same here

ersterhernd

@coldfire7 With all these 2.7.1 issues being reported, I'm going to leave well enough alone and forgo this update for the time being. 2.7.0 is working just fine as-is anyways. Newer isn't always better...

SteveITS

@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.”

stephenkwabena

@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

coldfire7

@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.

Zaf9670

@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.

coldfire7

@Zaf9670 No VLAN, but I have multiple WANs and I can access the GUI.

chris1284

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 run

pkg-static bootstrap -f

Installed a newer version than kernel
after this

pfSense-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

chris1284

This post is deleted!

reberhar

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.

StuartN

@stephenkwabena said in Upgrade pfsense CE 2.7.0 to 2.7.1:

certctl rehash

This worked for us. Thank you.

LHoust

@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???

reberhar

This post is deleted!

stephenw10

@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

@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.

stephenw10

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.

reberhar

@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

flat4

I updated with no issues