Pkg source switches from legacy to current

JeGr

Hi,

we have multiple systems that are currently forced to stay on legacy-2.3 patch until all kinks are worked out. I have them set to Legacy via the WebUI fine, but noticed, that quite a few have switched back to 2.4-current without anyone changing that (even audit log and backup history shows that change was 10/30 and today, but nothing the last days).

As we have written a simple and small check script that we run via NRPE, I’m trying to understand if that check script has something to do with it. But the only things it does is:

pkg-static update (to refresh the local package archive and see if there are new pfSense versions without anyone having to login to the dashboard)
pkg-static info pfSense (plus a few greps, sed’s etc. to check the installed version of pfSense via the pfSense meta package)
pkg-static search pfSense (plus greps etc. to check the new pfSense version via their meta package version number)

As all of these are non-changing pkg-static calls, I don’t see how they could trigger a upgrade/downgrade of the followed version. But I’ve clearly spottet change in the syslog by:

Time Process PID Message
Nov 14 14:25:01 pkg-static pfSense-repo downgraded: 2.4.1_3 -> 2.3.5_3
Nov 14 09:31:52 pkg-static pfSense-repo upgraded: 2.3.5_3 -> 2.4.1_3
Nov 13 10:33:20 pkg-static pfSense-repo upgraded: 2.3.4_14 -> 2.3.5_3

As no one logged into the system then myself at 14:20 the newest “downgrade” is me setting the device back to the legacy update path. But somehow it seems it has checked not only gotten the new 2.3.5_3 change yesterday but also switched to 2.4.1_3 today without anyone telling it so.

Hopefully someone can shed some light into that behavior

Greets,
Jens

jimp

In the past, the repo files were ambiguously named on the filesystem which made it harder to support the multiple options we have right now. One side effect of making them more specific, unfortunately, was that we couldn’t tell what the user had manually selected before apart from other items which might have had the same internal name.

For example if you were on 2.3.x and chose the option named “pfSense-devel” internally, it couldn’t tell that apart from someone on 2.4 who chose “pfSense-devel” even though they are two entirely different snapshot lines. They were different in the repository even though they had the same name, which was a lot of work to maintain.

So now things are the same on every branch but as you noticed, if you had picked some specific option it doesn’t necessarily line up with what is there now (either the name no longer exists or it has a different meaning now), but because of the previous ambiguity we can’t accurately guess at what the user wanted while keeping things consistent.

But if you choose an option now, and save, that should stick and won’t flip itself to something else from here on.

JeGr

But if you choose an option now, and save, that should stick and won’t flip itself to something else from here on.

As you say “now” was that a change with 2.3.5 updated? Because I see other strange things, like one of those boxes now having pfSense-2.3.5 meta package but all others (besides the repo) is still 2.3.4. That’s quite a strange mess currently.

Is some of that resulting due to us running above mentioned pkg updates/infos/searches daily? Or was that from some change pushed into 2.3.4 or 2.3.5?

Also the mentioned boxes with those settings flapping have a strange thing that if you select “current (2.4)” they can’t check for updates and package list is empty (in dashboard view), when you switch to 2.3.x legacy all is fine again.

Can you make sense of that?

jimp

If you set a 2.3.x box to see the 2.4.x repos then it won’t see packages because the package repos it’s aimed at are for 2.4, and you’re still on 2.3 so it needs the OS update to happen first. The list doesn’t show local packages because of a different bug (fixed on 2.4.2). It should still see the updates, though.

If something locally is out of sync you can set it to the correct branch and give it a nudge:

pkg-static install -f pkg pfSense-repo pfSense-upgrade

And even if the GUI doesn’t show an update, running option 13 or pfSense-upgrade from the console/ssh shell should work.

JeGr

If you set a 2.3.x box to see the 2.4.x repos then it won’t see packages because the package repos it’s aimed at are for 2.4

Understandable.

The list doesn’t show local packages because of a different bug (fixed on 2.4.2).

Ah! Thank you!

As said above, im curious as why one system of a CARP cluster “automagically” has pfSense-2.3.5 (Meta package) installed while the other still has 2.3.4 (which is correct). Both are still on 2.3.4-p1 as we have to schedule downtimes first with customers. So I don’t know where the Meta package change comes from (1) and why the systems (not only this two but 3 others, too) have started changing their update path back to current after 2.3.5 has been released. That’s a bit of a mystery ATM as a simple pkg-static update shouldn’t change a thing with the selected pkg repo.

Strange…

Thanks a lot for clarifying those other points!

Jens