pfSense 2.3.5 64bit NanoBSD upgrade to p2 problem
-
Hello. I setup new firewall with pfSense 2.3.5 64bit nanobsd. For some important reasons for me I need to use nanobsd version. My problem is update to p2 - I don't have option in branch firmware settings for 2.3.x, there is only option for 2.4.x. How can I resolve this issue and update firewall to p2? Thanks for help.
-
If it's 64-bit, you need to move to a full install of pfSense 2.4.4.
There are ways to get a similar effect to NanoBSD on a full install, such as activating the option to use RAM disks for
/varand/tmp. -
So if I understand updates for 2.3.x channel are stopped and not be available anymore?
-
Correct, 2.3 was obsolete the moment 2.4 was released. We maintained security updates for it for a year after that time, but that time has come. It's time to move forward.
-
Yes I understand this, but I want to install this security updates only, not the 2.4.x version - is this possible with 2.3.5 64bit NanoBSD or not?
-
The "security updates" for 64-bit systems are all on 2.4.4. You need to upgrade.
2.3 is EOL this month. There is not going to be a way to make it stay on 2.3.x because it is no longer secure to do so.
-
Thanks. Finally to be sure - 2.3.5 p2 version is ONLY for 32bit release. There is no p2 version for 64bit release. If I want this updates I need to install 2.4.x version, right?
-
There was never an installer for 2.3.5-p2 CE, only online updates, and at the moment, all of the update servers have been set to move compatible installs forward to 2.4.4 because that is the most secure option for them.
So before 2.4.4-RELEASE, it was possible to stay on 2.3.5-pX and get -p2, but not any more. Now any compatible hardware needs to be on 2.4.4-RELEASE or later.
-
Now I understand the whole picture, but I think it will be good for people like me in current situation to be able to install p2 release of 2.3.5. Not everyone need latest versions for long term installs. Thanks for help jimp!
-
You should not be installing an EOL version for "long term" use. That is not a secure practice.
We do make -pX installers for our factory version that goes on hardware we sell so they can ship with the latest versions installed. But that is not something we plan on offering for CE.
-
For me starting with the latest version is not a option for "in production" setup. Every latest version of any kind of software have hidden bugs. 2.3.5 is "in production" for few years and most of the bugs are resolved and for setup that I plan to use for the next 3 years before again make big upgrade of hardware and software it is the choice. For example in one place I use 2.1.5 because there is needed PPTP and for now this is the only choice - newer versions don't have PPTP server, but it is needed for very old factory machinery that is still in production.
-
That is a very, very wrong point of view. You are deliberately running insecure software, a practice we do not encourage and do not support.
One look at the changelog for any new version will show you dozens if not hundreds of bugs that were fixed after the version(s) you're using.
-
In working "in production" setup you can't push "Update" button as you can do in home and not every company can spend money to have backup hardware just sitting on the floor waiting if something went wrong to be used immediately.
-
That's why you test the upgrades in a lab setup with similar configurations and see what does or doesn't work for you long before a release, and then report said issues so they can be fixed in a release.
It helps nobody to run years-old versions of software and waiting for others to discover the issues.
-
Yes I agree. I test a lot of things in my home lab, but I will give you an example. Imagine that at this moment I have fully working setup with 2.3.5 p2 release and I decide to upgrade. O.K. lets do it, plan upgrade in the night when load of equipment is low, everything looks to be fine, but at 5:30 the phone rings - there is a problem. At this moment I have a backup of config xml file, but my problem is that I can't download my working version 2.3.5 p2 anymore, the company don't have money for spare equipment or don't want to spend money for it and in this situation what should I do? Report a bug and waiting for fix in second release? And with me all production department should wait, it is not possible. So I thing it is right to have an option to download every archived versions include Px releases just to be able to downgrade quickly to working setup while bug in new version is fixed.
-
@ilko-gd
Maybe a picture helps you to understand:
-
I mean...it's ugly, but you could just install the 32bit version and update that to 2.3.5p2. If you really have no other option.
What are you installing on that requires Nano?
Steve
-
@Grimson - 'In theory, there is no difference between theory and practice, in practice, there is'- Yogi Berra.
@stephenw10 - I can't use the 32bit version because in this setup I have 6GB of RAM, quad-core CPU and want to use the full power of the system. NanoBSD is great for me because it works with two partitions and after an upgrade, if there is a problem you can switch partition with good old one in minutes. This will be just router with firewall (2 WAN, VPN etc.) without any packages installed. Maybe I will give a try in the lab for 2.4.4 and search how to optimize full install for SSD drive.
-
If that's your worry, then swap the drive out for a blank drive, reinstall, then restore the config. If it blows up, put the old drive back in.
If you can't be down that long, you should have HA setup.
-
Yes, I think of it. Maybe I will buy 2 equal SSD drives and use one "in production" and another as a spare drive for upgrades. If after upgrade everything is working for two weeks I will reimage the spare drive with current version and config. Now I do the same thing with NanoBSD version.
