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?:
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.xmlfile 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.xmlfile and you are good to go. You would not reinstall the base system in that case. -
I understand all of that. Thanks though.
I was told the .xml file from 2.7.0 won’t work with reinstall of 2.6.0. I used the 2.6.0 xml. Worked fine. How it remembered the custom names for the NIC’s is all I was asking about.
-
@jsmiddleton4 said in What are the road signs we're getting close to a released version of 2.6?:
How it remembered the custom names for the NIC’s is all I was asking about.
He took valuable time to explain based on some of your previous responses. If one makes a copy of something, when one restores it again later, one shall get the exact copy including custom items in the copy...right? I am getting the feeling of your being a troll...
-
A troll?
He told me what is clear I already said I knew and didn’t provide any information regarding what I did ask.
I’m getting the feeling as I did before this forum has earned its reputation of being unfriendly.
Thanks though for taking the time to express your personal opinion of me.
-
@jsmiddleton4 said in What are the road signs we're getting close to a released version of 2.6?:
I was told the .xml file from 2.7.0 won’t work with reinstall of 2.6.0
Told by who - where is this thread where that was stated?
All depends on the version number of the config
https://docs.netgate.com/pfsense/en/latest/backup/restore.htmlAlso since the config file is really just text, you could always just use the xml to put stuff back that you might not have remembered.
But to be honest out of the box setups are not hard to just redo - how many rules did you have? How many interfaces did you have setup... I can not believe someone that doesn't even understand they are running dev, and the details and possible consequences of not running stable, etc. I don't seem them having 100s of rules or loads of interfaces or complex setups..
If your going to be playing with dev and beta and rc versions, etc.. It would behoove you to have backups of your previous config before you upgrade, etc.
-
@jsmiddleton4 said in What are the road signs we're getting close to a released version of 2.6?:
All but the names are consistent with the last backup for 2.6.0.
How the names stuck???The configuration file contains the customisation you have done to pfsense including any renaming you have done.
-
So when a configuration is restored the names are restored.
-
If names are restored they were in the configuration file you imported.
So the part of your question which does not make sense to me is why you expected the names not to be restored on this occasion. Perhaps:
- you believe they were not set in this particular configuration backup
- you assumed configuration backup for 2.6 would be very different to the configuration file for 2.7 (despite then being currently a few days different in code freeze)
Please clarify why you feel the names being there was unexpected then perhaps more helpful replies would be possible.
-
