What are the road signs we're getting close to a released version of 2.6?
-
@jsmiddleton4 said in What are the road signs we're getting close to a released version of 2.6?:
I didn’t say anything was out of the ordinary. I’m trying to clarify what IS ordinary.
I’ve gone to 2.7 thinking it was a 2.6.0 with improvements.
Apparently that is not exactly the case. 2.7.0 is a new family member.
Yes, back some time ago 2.4.5 was the RELEASE branch (RELENG_2_4_5 was the official branch name) and 2.5 was the Development Snapshot (also known as "Master"). Then one day the 2.5 development branch ("Master") suddenly became the new RELEASE branch (RELENG_2_5_0), and the previous RELEASE branch, 2.4.5, became deprecated. And what was originally 2.5 (or the development snapshot "Master" at that point in time) was renamed to be "2.6", and became the new "Master" development branch.
So on the date and time the rename discussed in this thread happened, 2.6 and 2.7 were identical code branches. At the point of renaming, though, 2.6 becomes basically frozen as the new RELEASE branch (first as RC, or Release Candidate, and then finally as RELENG_2_6_0 when it goes full production). And the 2.7 branch becomes the next Development Snapshot and is where future development work continues to happen. So 2.7 is now the Development Snapshot, and 2.6 is about to become the new Release.
That's not to say a few additional changes won't get into 2.6. If RC testing finds a major bug, then obviously that would be fixed in 2.6. But by and large future software changes are going to be continuing in the 2.7 branch while the 2.6 branch is about to become the production CE RELEASE.
-
I’m not finding any easy way to back out of 2.7.0 back to 2.6.0 other than save config.xml, local.conf file, etc. Install 2.6 clean, put config files back.
-
@jsmiddleton4
For now that is probably the only way. Eventually, once 2.6 officially becomes RELEASE, I think you will be able to swap back in the Update menu.But if you want to revert now, I would go the reinstall and restore config route.
You sort of "upgraded" at a bad time as you got in the in-between period where 2.6 is becoming RELEASE and the DEVEL snapshot branch is getting renamed to 2.7. So 2.6 is going to be 2.6-RC (Release Candidate), and what was formerly called 2.6-DEVEL is now renamed to 2.7-DEVEL.
-
Thanks. It feels like 2.6.0 release coming soon so will wait a bit.
-
-
-
@jegr said in What are the road signs we're getting close to a released version of 2.6?:
I'm not. Why should it?
Well, I had read awhile back (during 2.4.5 days) that the next release after 2.5 would be V3.0 and it makes sense currently at the pace things are going as FreeBSD 13 is now considered very stable and we have things that should have been or had been originally planned for v2.5 still in the table, such as REST API.
-
What's gonna happen with the next release, V3.0, etc., isn't what I've asked.
I need to get off the beta track. I mistakenly thought 2.7.0 was just more of the same on its way to the newest release candidate.
Its not. Newest release candidate will be 2.6.x. 2.7.0 doesn't end the beta track. It continues the beta track.
-
As Bill Meeks stated:
"But if you want to revert now, I would go the reinstall and restore config route."
That is the only way back to the 2.6.0 RC (with a config from 2.5.2 or 2.6.0 - if you save a config from the 2.7.0 branch it wont work) -
@nollipfsense said in What are the road signs we're getting close to a released version of 2.6?:
@jegr said in What are the road signs we're getting close to a released version of 2.6?:
I'm not. Why should it?
Well, I had read awhile back (during 2.4.5 days) that the next release after 2.5 would be V3.0 and it makes sense currently at the pace things are going as FreeBSD 13 is now considered very stable and we have things that should have been or had been originally planned for v2.5 still in the table, such as REST API.
I think that all the new things and features you mentioned, will see the light only in the Plus version. There is a direction, that all users to migrate to Plus version, if you'll want the latest and the greatest.
-
I have several backups including the one automatic backup that is labeled "before update".
The version number in the XML file says Version 22.2. Is that the same at 2.6.0 beta?
All of my xml files including backups since installing 2.7 say 22.2 version.
-
@jsmiddleton4 said in What are the road signs we're getting close to a released version of 2.6?:
The version number in the XML file says Version 22.2. Is that the same at 2.6.0 beta?
Version 2.6.0 RC: <version>22.2</version> (probably the 2.7.0 config will work on 2.6.0 RC)
Version 2.5.2: <version>21.7</version> -
I'm good to go then. Still might wait for 2.6.0 Stable Release. Blast 2.7, install stable 2.6, restore config.
-
@jsmiddleton4 I would stay away from 2.7 as I expect it is at alpha level (full designation is 2.7.0.a. ..........). I expect the "a" is for alpha and is truly bleeding edge stuff. I'll give it a look-see when it hits beta and only if the unresolved issues are minor or edge cases.
Just my approach.
Ted
-
Thanks. Had I known it was an alpha version I would've stayed clear.
-
I asked in a different thread about cleaning out the kernel.old folder as it was storing quite a few previous kernels from on going updates for 2.6.0.
There's no way to restore 2.6.0 from one of those *.old kernels?
If not, why are they saved?
-
@jsmiddleton4 That's a very good question and I don't have an answer. I'll leave it to others around here to respond.
Ted
-
@tquade There isn't much difference between a 2.6 kernel and a 2.7 kernel, right after the rebase.
At a certain point, everything is copied and renamed to 2.7 so development can continue.
2.6 becomes release candidate and any last minute fixes are applied.
Usually these are also forward ported to 2.7A kernel is kept in place as a best practice on all unix/linux systems.
If you cant boot current kernel, keep a backup of the previous that booted, and use it in an emergency.
Keeping many backup kernels is just a waste of space, which nowdays is amble.In practice, going back means reinstalling system and restoring configuration.
-
Thanks. I understand what a backup is and why you'd keep it. Doesn't explain why given there's a kernel.old you can't restore from those kernel.old's for 2.6.0 and I'd be back on track.
It seems to me for what I use PFSense for, basic router functions, its not likely I'll have an issue with 2.7.0. I'm not pushing PFSense to its limit by any means. Not a power user even in my dreams. While I wish I had not gone to 2.7.0 for my use/setting just how risky is it?
-
@jsmiddleton4 You shouldn't stay on dev version, if new things are introduced, updating will possibly break your installation.
And if you dont upgrade, isn't good for security too.Pfsense is a system running on freebsd.
So it is a complete os.
Restoring the os kernel, won't change anything else, and it won''t bring the system to the previous version.
This only works on monolithic router devices, where the .bak file is everything needed.This is not the case here.
-
Thanks. So the .old is for BSD, the operating system. Not a back up of PFSense?
I'm back to the 2.6.0RC. It only takes a second to restore.
Odd thing is I renamed my NIC's so I knew which client each was attached to, did it yesterday afternoon well into my third or fourth 2.7.0 update.
I used my 2.6.0 config for the config.xml on the thumbdrive to restore 2.6.0.
All the custom names remained in tact. I did not rename them when running 2.6.0.
The rules that I deleted yesterday were restored. Should have been as those "old" rules were in the config.xml for 2.6.0.
All but the names are consistent with the last backup for 2.6.0.
How the names stuck???
-
pfSense is a complicated and interconnected system. It starts with a customized FreeBSD kernel/operating system. Then layers of PHP code (for the GUI) and some custom binary executables/system services are added to make up the complete system.
So what you saw in that kernel directory was simply a small part of the entire system. You saw some of the FreeBSD part (the literal kernel). But that does not include all the PHP code and other things that live in all the other directories you see on a running system.
All of the configuration information for pfSense (which interface is what, the firewall rules, aliases, and all the stuff needed for the various packages) is stored in an XML file called
config.xml
. When you perform a backup in pfSense, literally all that is saved is that single XML file. That's because that file is all you need to restore a complete configuration. But realize that "configuration" is not the same as the base system. So typically when restoring a backup, you completely reinstall the base system if recovering from a disaster. Then after the base system is installed, you pull in the previousconfig.xml
file and that brings in all of your customized configuration. But if all you need to do is restore some previous configuration (say for example you borked your firewall rules or something), then you would only need to import the previousconfig.xml
file and you are good to go. You would not reinstall the base system in that case.