Is it safe to upgrade to 2.3.3?
-
I am currently running 2.3.2-RELEASE-p1 (i386) on nanobsd (4g) on PC Engines ALIX hardware.
While conducting my monthly security audit of my home network I noticed on my pfSense dashboard that 2.3.3 is now available.
In the past, almost all attempts to update this system have gone poorly. I certainly don't mean to sound ungrateful, I do appreciate the work that the developers do on pfSense, but the truth is that with each new release of pfSense there seem to be new regressions, useful packages get deprecated or removed (nrpe for example), etc. So before going down the rabbit hole and blowing up my firewall yet again, I thought I'd check here in the forums first. With that in mind, some specific questions:
(1) Has 2.3.3 been tested on ALIX hardware? If so, have those test results been published somewhere? Before attempting the upgrade I would like to see a detailed accounting of what components have been tested on this hardware, what testing methodology was use, and what the results of each test were. (If it hasn't then perhaps I can step up and do so, but I'll need to purchase an additional CompactFlash card before doing so; no point in re-inventing the wheel if it has already been done.)
(2) Is a comprehensive list of regressions and deprecations available for 2.3.3? I would like to know before upgrading which features may have been taken away from me this time around, or which features that worked properly in 2.3.2 are known to not work properly under 2.3.3, or which will require configuration changes in order to continue working under 2.3.3.
(3) For obvious reasons, I would like to make a backup of my system so that I will be able to get things running again if the upgrade fails. What is the current best practice for doing so? To be clear, I already have my configuration backed up (I do so every time I make a change.) I am referring to backing up the actual system image, i.e. the /dev/ada0s1 slice.
Note: I just tried to use the "Duplicate boot slice" feature available under Diagnostics -> NanoBSD, however that does not appear to work. It results in my browser reporting "Waiting for 192.168.2.1" for a long time, followed by a blank page being displayed (i.e. the header/menus are still there, but the content area of the page is blank.) After this, the UI is unresponsive for several minutes. During this time I can still connect via SSH, and top shows a dd process running, so it's possible that it completes successfully, but with no indication from the UI that the backup has completed successfully, I certainly can't trust it. Indeed, now that I've tried this, I do not know the current status of my backup slice:
Note 2: I considered simply dropping to a root shell and using dd to manually create a backup. I therefore went to Diagnostics -> NanoBSD to remount the root filesystem as read-only so I could safely do so, only to discover that pfSense now keeps the filesystem mounted read-write at all times. (In the location in the UI where it used to be possible to control the read-write/read-only mount status there is now only text that says "NanoBSD is now always read-write to avoid read-write to read-only mount problems.") I therefore can not safely use dd to do this either. Is there a way to work around that? Can I safely remount the root filesystem as read-only from the command line?
Note 3: I considered simply downloading the 2.3.2 image from the pfSense web site and keeping that on-hand in case things go badly, however that no longer seems to be available; all download links on the public-facing pfSense web site seem to be to 2.3.3 images only. Are the 2.3.2 images archived somewhere that I can download them?
Thanks in advance for your assistance!
-
-
No need to buy a new CF card, simply take a disk image. On *nix, use dd. Ex: "dd if=/dev/sdX of=/tmp/pf-2.3.2.img" Do this on a different system or boot a live environment on the ALIX, don't try to do it from the fs you are imaging. On Windows use Win32DiskImager, it's self explanatory.
-
As always all regressions are listed in the blog.
-
See 1.
Hope that helps.
-
-
I have upgraded my Alix2D13 with no problems. I am using the core system (firewall rules…) plus OpenVPN site-to-site, Dyn DNS and it has a WiFi card in it. It takes time to upgrade, because the CF card seems to be getting slower and slower, but it does work.
As long as you now how to access the physical serial console, then you can switch back to the original boot slice easily if something goes wrong with writing the upgraded stuff to the opposite slice and it has a boot problem. For the upgrade, everything new is written to the "other" slice, so there is no point in first doing a "duplicate slice". The upgrade process is going to do that anyway.
The upgrade code is good at bailing out if anything goes wrong with writing the "other" slice. So if your CF card has write problems then the upgrade will stop and bail out before switching the boot slice. It would only be if the CF card has some undetected read back problem that there would be trouble when rebooting with the "other" slice.
2.3.3 uses the same underlying FreeBSD 10.3 with the latest security patches... so I am not aware of any regressions in that area since 2.3.2. The pfSense webGUI and startup/controlling PHP etc scripts have plenty of fixes as in the release notes.
IMHO the issue with old Alix systems is that the CF cards get slower and then die - a hardware problem. I have a few of them in service, and I hate to throw out working electronics, but the reality is that the CF cards are becoming less reliable. The end of the road for pfSense support is the 2.3.* release series, and actually that turns out to be about the right time frame to be forced to replace them with something else.
-
-
No need to buy a new CF card, simply take a disk image. On *nix, use dd. Ex: "dd if=/dev/sdX of=/tmp/pf-2.3.2.img" Do this on a different system or boot a live environment on the ALIX, don't try to do it from the fs you are imaging. On Windows use Win32DiskImager, it's self explanatory.
-
As always all regressions are listed in the blog.
-
See 1.
Hope that helps.
Thank you, yes, that helps tremendously, that was exactly what I was looking for. Sometimes it's just hard to find what you need. :-)
With regards to buying a new flash card, I actually just meant if the pfSense team was looking for a volunteer to do testing on the ALIX platform, since for that I wouldn't want to mess with my production firewall. (I actually have a spare ALIX router, but only one CompatFlash card at the moment.)
Making an image on another box is a great idea, although I still wish that the slice backup feature worked reliably, since I need to take myself offline for a while to do the image on another machine. Fortunately I have a USB to CompactFlash adapter, so I just popped it into a Linux box and dd'ed all three partitions.
-
-
IMHO the issue with old Alix systems is that the CF cards get slower and then die - a hardware problem. I have a few of them in service, and I hate to throw out working electronics, but the reality is that the CF cards are becoming less reliable. The end of the road for pfSense support is the 2.3.* release series, and actually that turns out to be about the right time frame to be forced to replace them with something else.
Ah, bummer, I didn't know they were end of lifeing the platform. :-( Sigh. I'm one of those old farts that really, really hates upgrading something when it's working fine and "not broken". Of course with a public-facing firewall, not having updates quickly leads to "broken". I may need to move to something else, I guess I'll figure that out when the time comes.
I'm not sure I really understand about the CF reliability though. Aren't they still manufacturing them? I just did a quick search and they still seem to be readily available. Or are you saying the ones being made now are no good? (I remember when floppy disks hit end of life the same thing happened… for the last few years all the brand new floppies being produced were just absolute junk... yeah, I'm old, lol.) :-(
Thanks for the help!
-
Well, I took Mech's advice and used dd to make a backup on another system (and downloaded a 2.3.2 image from the archive just to be safe… I'm paranoid.)
Unfortunately, the upgrade failed. Le sigh. :-( I tried it multiple times with the same results. As Phil said it handled it gracefully, leaving the boot partition untouched, so I'm still up.
This is the output after trying to use the upgrade option from the GUI. Any ideas? Should I just start with a new 2.3.3 install, and restore my config file to it? Is the config file format compatible between versions?
>>> Updating repositories metadata... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. >>> Upgrading pkg... done. >>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.txz: . done Fetching packagesite.txz: . done Processing entries: .. done pfSense-core repository update completed. 12 packages processed. Updating pfSense repository catalogue... Fetching meta.txz: . done Fetching packagesite.txz: .......... done Processing entries: .......... done pfSense repository update completed. 432 packages processed. >>> Upgrading pfSense-repo... done. >>> Updating repositories metadata... Updating pfSense-core repository catalogue... Repository pfSense-core has a wrong packagesite, need to re-create database Fetching meta.txz: . done Fetching packagesite.txz: . done Processing entries: .. done pfSense-core repository update completed. 12 packages processed. Updating pfSense repository catalogue... Repository pfSense has a wrong packagesite, need to re-create database Fetching meta.txz: . done Fetching packagesite.txz: .......... done Processing entries: .......... done pfSense repository update completed. 432 packages processed. **** WARNING **** Duplicate slice required!! Before starting the upgrade process, the currently mounted nanobsd partition needs to be cloned to the secondary partition, where the update will happen After installation a reboot will be required to switch partition. >>> Cleaning secondary partition... done. >>> Duplicating current slice... done. >>> Restoring slice label... done. >>> Testing duplicated partition integrity... done. >>> Mounting second partition to run upgrade... done. >>> Copying resolv.conf to upgrade partition... done. >>> Unlocking package pfSense-kernel-pfSense_wrap... done. >>> Downloading upgrade packages... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. Checking for upgrades (80 candidates): .......... done Processing candidates (80 candidates): .......... done The following 85 package(s) will be affected (of 0 checked): New packages to be INSTALLED: libnghttp2: 1.18.0 [pfSense] openvpn23: 2.3.14 [pfSense] norm: 1.5r6 [pfSense] libwww: 5.4.0_6 [pfSense] json-c: 0.12.1 [pfSense] Installed packages to be UPGRADED: wol: 0.7.1_2 -> 0.7.1_3 [pfSense] unbound: 1.5.9 -> 1.6.0 [pfSense] uclcmd: 0.1 -> 0.1_1 [pfSense] strongswan: 5.5.0 -> 5.5.1 [pfSense] sqlite3: 3.13.0 -> 3.15.1_1 [pfSense] python27: 2.7.12 -> 2.7.13_1 [pfSense] php56-zlib: 5.6.26 -> 5.6.30 [pfSense] php56-xmlwriter: 5.6.26 -> 5.6.30 [pfSense] php56-xmlreader: 5.6.26 -> 5.6.30 [pfSense] php56-xml: 5.6.26 -> 5.6.30 [pfSense] php56-tokenizer: 5.6.26 -> 5.6.30 [pfSense] php56-sysvshm: 5.6.26 -> 5.6.30 [pfSense] php56-sysvsem: 5.6.26 -> 5.6.30 [pfSense] php56-sysvmsg: 5.6.26 -> 5.6.30 [pfSense] php56-sqlite3: 5.6.26 -> 5.6.30 [pfSense] php56-sockets: 5.6.26 -> 5.6.30 [pfSense] php56-simplexml: 5.6.26 -> 5.6.30 [pfSense] php56-shmop: 5.6.26 -> 5.6.30 [pfSense] php56-session: 5.6.26 -> 5.6.30 [pfSense] php56-readline: 5.6.26 -> 5.6.30 [pfSense] php56-posix: 5.6.26 -> 5.6.30 [pfSense] php56-pfSense-module: 0.12 -> 0.13 [pfSense] php56-pdo_sqlite: 5.6.26 -> 5.6.30 [pfSense] php56-pdo: 5.6.26 -> 5.6.30 [pfSense] php56-pcntl: 5.6.26 -> 5.6.30 [pfSense] php56-openssl: 5.6.26 -> 5.6.30 [pfSense] php56-opcache: 5.6.26_1 -> 5.6.30 [pfSense] php56-mcrypt: 5.6.26 -> 5.6.30 [pfSense] php56-mbstring: 5.6.26 -> 5.6.30 [pfSense] php56-ldap: 5.6.26 -> 5.6.30 [pfSense] php56-json: 5.6.26 -> 5.6.30 [pfSense] php56-hash: 5.6.26 -> 5.6.30 [pfSense] php56-gettext: 5.6.26 -> 5.6.30 [pfSense] php56-filter: 5.6.26 -> 5.6.30 [pfSense] php56-dom: 5.6.26 -> 5.6.30 [pfSense] php56-curl: 5.6.26 -> 5.6.30 [pfSense] php56-ctype: 5.6.26 -> 5.6.30 [pfSense] php56-bz2: 5.6.26 -> 5.6.30 [pfSense] php56-bcmath: 5.6.26 -> 5.6.30 [pfSense] php56: 5.6.26 -> 5.6.30 [pfSense] php-xdebug: 2.4.0 -> 2.4.1_1 [pfSense] php-suhosin: 0.9.38 -> 0.9.38_3 [pfSense] pftop: 0.7_6 -> 0.7_7 [pfSense] pfSense-rc: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-kernel-pfSense_wrap: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-default-config-serial: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-base-nanobsd: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-Status_Monitoring: 1.4.4_2 -> 1.6.1_3 [pfSense] pfSense: 2.3.2_1 -> 2.3.3 [pfSense] perl5: 5.20.3_15 -> 5.24.1.r4_1 [pfSense] pecl-zmq: 1.1.3_1 -> 1.1.3_2 [pfSense] pecl-ssh2: 0.12 -> 0.13 [pfSense] pecl-rrd: 1.1.3_3 -> 1.1.3_4 [pfSense] pecl-radius: 1.3.0 -> 1.4.0.b1 [pfSense] pcre: 8.39 -> 8.39_1 [pfSense] ntp: 4.2.8p8 -> 4.2.8p9_1 [pfSense] nginx: 1.10.1,2 -> 1.10.2_3,2 [pfSense] nettle: 3.2 -> 3.3 [pfSense] nagios-plugins: 2.1.1_5,1 -> 2.1.4,1 [pfSense] links: 2.9,1 -> 2.13,1 [pfSense] libzmq4: 4.1.4_1 -> 4.1.5 [pfSense] libssh2: 1.7.0,2 -> 1.8.0,2 [pfSense] libsodium: 1.0.8 -> 1.0.11_1 [pfSense] libiconv: 1.14_9 -> 1.14_10 [pfSense] isc-dhcp43-server: 4.3.4 -> 4.3.5 [pfSense] isc-dhcp43-relay: 4.3.4_1 -> 4.3.5 [pfSense] isc-dhcp43-client: 4.3.4 -> 4.3.5 [pfSense] indexinfo: 0.2.4 -> 0.2.6 [pfSense] idnkit: 1.0_5 -> 1.0_6 [pfSense] glib: 2.46.2 -> 2.46.2_4 [pfSense] gettext-runtime: 0.19.8.1 -> 0.19.8.1_1 [pfSense] expat: 2.1.1_2 -> 2.2.0_1 [pfSense] dhcp6: 20080615_7 -> 20080615.1 [pfSense] curl: 7.50.3 -> 7.52.1_1 [pfSense] ca_root_nss: 3.25 -> 3.28.1 [pfSense] bind-tools: 9.10.4P2 -> 9.11.0P3 [pfSense] Installed packages to be REINSTALLED: scponly-4.8.20110526_2 [pfSense] (options changed) rrdtool-1.6.0_1 [pfSense] (direct dependency changed: perl5) nrpe-ssl-2.15_6 [pfSense] (option removed: SSL) miniupnpd-1.9.20160113,1 [pfSense] (options changed) Number of packages to be installed: 5 Number of packages to be upgraded: 76 Number of packages to be reinstalled: 4 The process will require 20 MiB more space. 82 MiB to be downloaded. Fetching wol-0.7.1_3.txz: ... done Fetching unbound-1.6.0.txz: .......... done Fetching uclcmd-0.1_1.txz: .. done Fetching strongswan-5.5.1.txz: .......... done Fetching sqlite3-3.15.1_1.txz: .......... done Fetching scponly-4.8.20110526_2.txz: .. done Fetching rrdtool-1.6.0_1.txz: .......... done Fetching python27-2.7.13_1.txz: .......... done Fetching php56-zlib-5.6.30.txz: .. done Fetching php56-xmlwriter-5.6.30.txz: .. done Fetching php56-xmlreader-5.6.30.txz: .. done Fetching php56-xml-5.6.30.txz: .. done Fetching php56-tokenizer-5.6.30.txz: . done Fetching php56-sysvshm-5.6.30.txz: . done Fetching php56-sysvsem-5.6.30.txz: . done Fetching php56-sysvmsg-5.6.30.txz: . done Fetching php56-sqlite3-5.6.30.txz: .. done Fetching php56-sockets-5.6.30.txz: .... done Fetching php56-simplexml-5.6.30.txz: ... done Fetching php56-shmop-5.6.30.txz: . done Fetching php56-session-5.6.30.txz: ... done Fetching php56-readline-5.6.30.txz: .. done Fetching php56-posix-5.6.30.txz: . done Fetching php56-pfSense-module-0.13.txz: ... done Fetching php56-pdo_sqlite-5.6.30.txz: .. done Fetching php56-pdo-5.6.30.txz: ..... done Fetching php56-pcntl-5.6.30.txz: .. done Fetching php56-openssl-5.6.30.txz: ..... done Fetching php56-opcache-5.6.30.txz: ...... done Fetching php56-mcrypt-5.6.30.txz: .. done Fetching php56-mbstring-5.6.30.txz: .......... done Fetching php56-ldap-5.6.30.txz: .. done Fetching php56-json-5.6.30.txz: .. done Fetching php56-hash-5.6.30.txz: .......... done Fetching php56-gettext-5.6.30.txz: . done Fetching php56-filter-5.6.30.txz: .. done Fetching php56-dom-5.6.30.txz: ...... done Fetching php56-curl-5.6.30.txz: ... done Fetching php56-ctype-5.6.30.txz: . done Fetching php56-bz2-5.6.30.txz: .. done Fetching php56-bcmath-5.6.30.txz: .. done Fetching php56-5.6.30.txz: .......... done Fetching php-xdebug-2.4.1_1.txz: ......... done Fetching php-suhosin-0.9.38_3.txz: ...... done Fetching pftop-0.7_7.txz: ...... done Fetching pfSense-rc-2.3.3.txz: . done Fetching pfSense-kernel-pfSense_wrap-2.3.3.txz: .......... done Fetching pfSense-default-config-serial-2.3.3.txz: . done Fetching pfSense-base-nanobsd-2.3.3.txz: .......... done Fetching pfSense-Status_Monitoring-1.6.1_3.txz: .. done Fetching pfSense-2.3.3.txz: . done Fetching perl5-5.24.1.r4_1.txz: .......... done Fetching pecl-zmq-1.1.3_2.txz: ... done Fetching pecl-ssh2-0.13.txz: ... done Fetching pecl-rrd-1.1.3_4.txz: .. done Fetching pecl-radius-1.4.0.b1.txz: ... done Fetching pcre-8.39_1.txz: .......... done Fetching ntp-4.2.8p9_1.txz: .......... done Fetching nrpe-ssl-2.15_6.txz: ... done Fetching nginx-1.10.2_3,2.txz: .......... done Fetching nettle-3.3.txz: .......... done Fetching nagios-plugins-2.1.4,1.txz: .......... done Fetching miniupnpd-1.9.20160113,1.txz: ...... done Fetching links-2.13,1.txz: .......... done Fetching libzmq4-4.1.5.txz: .......... done Fetching libssh2-1.8.0,2.txz: .......... done Fetching libsodium-1.0.11_1.txz: .......... done Fetching libiconv-1.14_10.txz: .......... done Fetching isc-dhcp43-server-4.3.5.txz: .......... done Fetching isc-dhcp43-relay-4.3.5.txz: .......... done Fetching isc-dhcp43-client-4.3.5.txz: .......... done Fetching indexinfo-0.2.6.txz: . done Fetching idnkit-1.0_6.txz: .......... done Fetching glib-2.46.2_4.txz: .......... done Fetching gettext-runtime-0.19.8.1_1.txz: .......... done Fetching expat-2.2.0_1.txz: .......... done Fetching dhcp6-20080615.1.txz: .......... done Fetching curl-7.52.1_1.txz: .......... done Fetching ca_root_nss-3.28.1.txz: .......... done Fetching bind-tools-9.11.0P3.txz: .......... done Fetching libnghttp2-1.18.0.txz: .......... done Fetching openvpn23-2.3.14.txz: .......... done Fetching norm-1.5r6.txz: .......... done Fetching libwww-5.4.0_6.txz: .......... done Fetching json-c-0.12.1.txz: .... done Checking integrity... done (1 conflicting) - openvpn23-2.3.14 [pfSense] conflicts with openvpn-2.3.11 [installed] on /usr/local/include/openvpn-plugin.h Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 86 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: openvpn-2.3.11 New packages to be INSTALLED: libnghttp2: 1.18.0 [pfSense] norm: 1.5r6 [pfSense] libwww: 5.4.0_6 [pfSense] json-c: 0.12.1 [pfSense] openvpn23: 2.3.14 [pfSense] Installed packages to be UPGRADED: indexinfo: 0.2.4 -> 0.2.6 [pfSense] gettext-runtime: 0.19.8.1 -> 0.19.8.1_1 [pfSense] python27: 2.7.12 -> 2.7.13_1 [pfSense] perl5: 5.20.3_15 -> 5.24.1.r4_1 [pfSense] pcre: 8.39 -> 8.39_1 [pfSense] libiconv: 1.14_9 -> 1.14_10 [pfSense] glib: 2.46.2 -> 2.46.2_4 [pfSense] expat: 2.1.1_2 -> 2.2.0_1 [pfSense] ca_root_nss: 3.25 -> 3.28.1 [pfSense] unbound: 1.5.9 -> 1.6.0 [pfSense] php56: 5.6.26 -> 5.6.30 [pfSense] libsodium: 1.0.8 -> 1.0.11_1 [pfSense] curl: 7.50.3 -> 7.52.1_1 [pfSense] strongswan: 5.5.0 -> 5.5.1 [pfSense] sqlite3: 3.13.0 -> 3.15.1_1 [pfSense] php56-session: 5.6.26 -> 5.6.30 [pfSense] php56-pdo: 5.6.26 -> 5.6.30 [pfSense] php56-dom: 5.6.26 -> 5.6.30 [pfSense] pecl-rrd: 1.1.3_3 -> 1.1.3_4 [pfSense] nettle: 3.2 -> 3.3 [pfSense] libzmq4: 4.1.4_1 -> 4.1.5 [pfSense] libssh2: 1.7.0,2 -> 1.8.0,2 [pfSense] idnkit: 1.0_5 -> 1.0_6 [pfSense] wol: 0.7.1_2 -> 0.7.1_3 [pfSense] uclcmd: 0.1 -> 0.1_1 [pfSense] php56-zlib: 5.6.26 -> 5.6.30 [pfSense] php56-xmlwriter: 5.6.26 -> 5.6.30 [pfSense] php56-xmlreader: 5.6.26 -> 5.6.30 [pfSense] php56-xml: 5.6.26 -> 5.6.30 [pfSense] php56-tokenizer: 5.6.26 -> 5.6.30 [pfSense] php56-sysvshm: 5.6.26 -> 5.6.30 [pfSense] php56-sysvsem: 5.6.26 -> 5.6.30 [pfSense] php56-sysvmsg: 5.6.26 -> 5.6.30 [pfSense] php56-sqlite3: 5.6.26 -> 5.6.30 [pfSense] php56-sockets: 5.6.26 -> 5.6.30 [pfSense] php56-simplexml: 5.6.26 -> 5.6.30 [pfSense] php56-shmop: 5.6.26 -> 5.6.30 [pfSense] php56-readline: 5.6.26 -> 5.6.30 [pfSense] php56-posix: 5.6.26 -> 5.6.30 [pfSense] php56-pfSense-module: 0.12 -> 0.13 [pfSense] php56-pdo_sqlite: 5.6.26 -> 5.6.30 [pfSense] php56-pcntl: 5.6.26 -> 5.6.30 [pfSense] php56-openssl: 5.6.26 -> 5.6.30 [pfSense] php56-opcache: 5.6.26_1 -> 5.6.30 [pfSense] php56-mcrypt: 5.6.26 -> 5.6.30 [pfSense] php56-mbstring: 5.6.26 -> 5.6.30 [pfSense] php56-ldap: 5.6.26 -> 5.6.30 [pfSense] php56-json: 5.6.26 -> 5.6.30 [pfSense] php56-hash: 5.6.26 -> 5.6.30 [pfSense] php56-gettext: 5.6.26 -> 5.6.30 [pfSense] php56-filter: 5.6.26 -> 5.6.30 [pfSense] php56-curl: 5.6.26 -> 5.6.30 [pfSense] php56-ctype: 5.6.26 -> 5.6.30 [pfSense] php56-bz2: 5.6.26 -> 5.6.30 [pfSense] php56-bcmath: 5.6.26 -> 5.6.30 [pfSense] php-xdebug: 2.4.0 -> 2.4.1_1 [pfSense] php-suhosin: 0.9.38 -> 0.9.38_3 [pfSense] pftop: 0.7_6 -> 0.7_7 [pfSense] pfSense-rc: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-Status_Monitoring: 1.4.4_2 -> 1.6.1_3 [pfSense] pecl-zmq: 1.1.3_1 -> 1.1.3_2 [pfSense] pecl-ssh2: 0.12 -> 0.13 [pfSense] pecl-radius: 1.3.0 -> 1.4.0.b1 [pfSense] ntp: 4.2.8p8 -> 4.2.8p9_1 [pfSense] nginx: 1.10.1,2 -> 1.10.2_3,2 [pfSense] nagios-plugins: 2.1.1_5,1 -> 2.1.4,1 [pfSense] links: 2.9,1 -> 2.13,1 [pfSense] isc-dhcp43-server: 4.3.4 -> 4.3.5 [pfSense] isc-dhcp43-relay: 4.3.4_1 -> 4.3.5 [pfSense] isc-dhcp43-client: 4.3.4 -> 4.3.5 [pfSense] dhcp6: 20080615_7 -> 20080615.1 [pfSense] bind-tools: 9.10.4P2 -> 9.11.0P3 [pfSense] pfSense-kernel-pfSense_wrap: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-default-config-serial: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-base-nanobsd: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense: 2.3.2_1 -> 2.3.3 [pfSense] Installed packages to be REINSTALLED: rrdtool-1.6.0_1 [pfSense] (direct dependency changed: perl5) scponly-4.8.20110526_2 [pfSense] (options changed) miniupnpd-1.9.20160113,1 [pfSense] (options changed) nrpe-ssl-2.15_6 [pfSense] (option removed: SSL) Number of packages to be removed: 1 Number of packages to be installed: 5 Number of packages to be upgraded: 76 Number of packages to be reinstalled: 4 The process will require 20 MiB more space. >>> Upgrading pfSense kernel... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 2 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense-kernel-pfSense_wrap: 2.3.2_1 -> 2.3.3 [pfSense-core] pfSense-rc: 2.3.2_1 -> 2.3.3 [pfSense-core] Number of packages to be upgraded: 2 [1/2] Upgrading pfSense-rc from 2.3.2_1 to 2.3.3... [1/2] Extracting pfSense-rc-2.3.3: .... done [2/2] Upgrading pfSense-kernel-pfSense_wrap from 2.3.2_1 to 2.3.3... pkg: sqlite error while executing INSERT INTO files (path, sha256, package_id) VALUES (?1, ?2, ?3) in file pkgdb.c:1700: database disk image is malformed >>> Locking package pfSense-kernel-pfSense_wrap... done. Failed -
New CF cards should be fine. I meant that a CF card that has been in use for some time (i.e. had quite a few cycles of writes…) gets slower and eventually writes start to fail. So many Alix systems that have been in use for some years and seen a few upgrades and had a "not so great CF card" in the first place will be getting slow and possibly failing to upgrade.
I have no peer-reviewed study to quantify "for some time", "seen a few upgrades" or "not so great CF card".
I would guess that the fail in your upgrade log is something to do with the CF card struggling. Unfortunately it ran for a long time, duplicating the slice, downloading all the upgrade packages and so on before an error - that's enhanced Murphy's law at work.
Old configs upgrade fine from any old version. So you can write 2.3.3 release to a CF card, boot it in your system and restore your previous config. When the system reboots it will upgrade anything it needs to in the config.
-
As a side note here - the "duplicate slice" feature is completely irrelevant here. The slice is always duplicated before upgrade and the upgrade happens there.
-
I would guess that the fail in your upgrade log is something to do with the CF card struggling. Unfortunately it ran for a long time, duplicating the slice, downloading all the upgrade packages and so on before an error - that's enhanced Murphy's law at work.
Thanks Phil,
I certainly don't want to get into an argument about CompactFlash, and I admit I'm not a subject matter expert in that domain, but I am a bit skeptical that all my pfSense problems are due to "you must just have a bad CompactFlash".
I was one of the people affected by pfSense bug 4814 / FreeBSD bug 176169 (slow remounts on CompactFlash.) At the time, the pfSense team didn't really seem to be interested in addressing that issue, even when a patch was offered in 176169. They insisted that the root cause was just slow/bad CompactFlash cards, and said that they would "attempt to develop a solution. But this patch is not that solution", with no further explanation of why that patch was not a valid solution other than "it's dangerous". (I'm sure there was a valid reason, but it wasn't disclosed in more detail than that in the bug report.)
Eventually 4814 was closed as "normal behavior", and at one point I was told by someone (I forget who now) that I should stop being so cheap and just go buy new media. (I admit, I am a cheap-o.) :-) Well, despite being on a limited budget, I did just that, and bought a brand new 4GB CompactFlash card. While this did reduce the delay described in 4814 noticeably, it was by no means a fix (if memory serves, the delay went from about a minute to about 30 seconds), and again, this was with a brand new, brand name, fairly fast, well-rated card. Over the past two years I've run pfSense on at least 3 different CF cards, and all exhibited this behavior, some worse than others, but they've all been significant. The suggested workaround in the bug report was to leave the card mounted read-write at all times, and indeed, per my comment earlier in this thread, it appears that that was what was eventually implemented as a "fix" for this bug, write-wear be damned. :-(
Chris Buechle closed the bug, with the comment that he had only observed it in "one make and model each of CF and SD card made in the last 7 years". I have no idea how big his sample of cards was (he only described it as "a stack"), but finding an outlier in each card type that easily still sounds statistically significant to me, especially combined with my own personal experience (I realize that my three attempts represent a statistically small sample, but still… do I really just have phenomenally bad luck?)
Do I just keep buying random cards until I get one that works? At what point does it become a legitimate problem? When I have 5 cards in a row that don't work? 10? I realize CF isn't horribly expensive, but they're not free either.
Anyway, since pfSense is dropping support for ALIX, it's probably just time for me to move on to another platform. OpnSense looks interesting, and there seem to still be a number of other solutions that support ALIX (according to the ALIX web site at least, I haven't had a chance to personally investigate them.)
It's a shame, because I really like pfSense, and the fact that it runs on BSD. However, it is what it is.
Thanks again for your help with this. I'm going to try reflashing 2.3.3 directly and restoring my config. I probably won't get a chance to until this evening though. I'll post an update with my results though!
-
I'm going to try reflashing 2.3.3 directly and restoring my config. I probably won't get a chance to until this evening though. I'll post an update with my results though!
Well, I shut down the firewall, moved the flash to a Linux box, used DD to write the new image, reinstalled it, restored my config, and after quite a bit of churning (downloading packages, regenerating SSH keys, and such), things finally got back to normal. Things seem to be stable and so far all of the packages I am using seem to be working properly. Quite the cumbersome update process for something that's supposed to be "click here to update", but at least in the end it works.
One oddity is that on my dashboard under version it now shows this:
2.3.3-RELEASE (i386) built on Thu Feb 16 06:59:50 CST 2017 FreeBSD 10.3-RELEASE-p16 The system is on a later version than the official release.That seems to be in error, since this is the official release, correct? I got it directly from the public-facing web site.
Also, while downloading the new image I noticed an inaccuracy on the pfSense web site's download page (https://pfsense.org/download/) It incorrectly states:
"The embedded version is meant to be written to disc before use and is specifically tailored for use with any hardware using flash memory (mostly Compact Flash) rather than a hard drive. Flash memory can only handle a limited number of writes, so the embedded version runs read only from flash, with read/write file systems as RAM disks."
This is out of date and misleading. I was going to submit a bug report, but could not find a category for the web site, so the bug tracking system may not be the right place to report that, but I'm not sue who I should report it to. Hopefully someone reading this will know.
At least I'm up and running for now.
Unfortunately it looks like I need to start looking for a new firewall solution though, given the end-of-life thing. Bummer. :-( Thanks for the heads up on that though! Do we know when the actual target date is for ALIX support to end?
And I guess to answer my own question that I started this thread with: No! It is definitely not safe to upgrade to 2.3.3 on ALIX! (Well, not the automated, GUI way at least.) :-)
-
And I guess to answer my own question that I started this thread with: No! It is definitely not safe to upgrade to 2.3.3 on ALIX! (Well, not the automated, GUI way at least.)
I will (politely) disagree. The upgrade procedure is safe, it has not left me with a [broken|unbootable|bricked] system.
The issues are:
- It is slow (depends on the CF card)
- If it gets part way through downloading the upgrade files and something goes wrong with the download then the process is too "stupid" and starts all over again duplicating the slice… - annoying
- If it gets some CF card write error - but at least it gives up and does not switch to the half-written slice.
On the end of i386 support - yes, I also get annoyed at the waste in the electronics/computing industry. In small home/offices that are nowhere near getting 100Mbps internet the Alix runs fine. e.g. I have a 10Mbps connection and never notice any problem. It is a shame to chuck out the Alix board. But actually getting rid of crud CF cards is a good thing (but not strictly related to i386!)
-
I will (politely) disagree. The upgrade procedure is safe, it has not left me with a [broken|unbootable|bricked] system.
You're absolutely right, and I actually don't disagree with you: "safe" was a bad word choice on my part. (I did mention it was late… I think about 4:00 am here in Seattle by the time I finally finished up and posted that last night.) :-(
The upgrade certainly did not leave me with an unbootable or unusable system at any point. However, the gui-based upgrade does consistently fail and is not usable to upgrade, that was what I was (poorly) trying to express. So it is "safe", but it also just doesn't work, and the workaround I used certainly wasn't safe (but that's why we make backups.)
Although in the end I got it done, the upgrade (including my posts here on the forum and the upgrade itself) cost me many hours of time over the past few days. I wasn't really tracking it, but I'd guesstimate I've lost the equivalent of a full 8-hour workday to it. For an embedded system that is meant to be user-friendly with a web based administrative GUI, that's kind of lame in this day and age. If the GUI is going to provide a "an update is available, click here to install it" option, it should work, not lead the user down a rabbit hole that requires many hours of time, and fairly advance sysadmin abilities to resolve. (I'm perfectly comfortable with the process, but the majority of people I've provided IT support to over the years you would never want going anywhere near something like dd.) :-)
So, it's just frustrating. As I said in the beginning, I really do appreciate all the effort that has gone into pfSense, I don't mean any disrespect to the development team. It's still frustrating having to deal with all this for what should be a routine update though (and from my personal experience, every recent pfSense update has been very painful, some even more so than this one.)
- It is slow (depends on the CF card)
- If it gets some CF card write error - but at least it gives up and does not switch to the half-written slice.
You and your CF hating! (kidding.) :-) For what it's worth, I ordered yet another 4GB CF card last night. It should be here in a few days. I mainly bought it so I could try out alternatives to pfSense on my spare ALIX, but if I can find the time I'm also going to put 2.3.2 on it and try the 2.3.2 -> 2.3.3 update again, to see if it makes any difference. I'll report back if I do.
On the end of i386 support - yes, I also get annoyed at the waste in the electronics/computing industry. In small home/offices that are nowhere near getting 100Mbps internet the Alix runs fine. e.g. I have a 10Mbps connection and never notice any problem. It is a shame to chuck out the Alix board.
Exactly. I've run this on as fast as a 50Mbps Internet uplink. It's also my VPN termination when accessing my home network from outside, my DHCP server and local DNS resolver, my NRPE intermediary for monitoring my home network resources from my external monitoring server, etc. Excellent performance on all counts, in fact it's barely even trying. There's no need to replace it. In fact the only place that it seems to fall down is applying updates.
But actually getting rid of crud CF cards is a good thing (but not strictly related to i386!)
Oh, there you go again! Hehehe. :-P
I've noticed the ALIX boards do have solder points for an ATA header adjacent to the CF. Perhaps it would be possible to put something else in them? A hard drive seems like overkill though, actually feels like a step backwards for an embedded system.
-
For what it's worth, I ordered yet another 4GB CF card last night. It should be here in a few days. I mainly bought it so I could try out alternatives to pfSense on my spare ALIX, but if I can find the time I'm also going to put 2.3.2 on it and try the 2.3.2 -> 2.3.3 update again, to see if it makes any difference. I'll report back if I do.
Well, the new CF arrived and I finally had a chance to test it out today. I used dd to write a bit-for-bit copy of my previous 2.3.2 install onto it, so everything was exactly as before, and then I tried using the update button in the GUI to go from 2.3.2 -> 2.3.3 again. It failed again, in exactly the same way and place as the previous attempt failed.
This is a brand new Kingston card:
https://www.amazon.com/Kingston-CompactFlash-Memory-CF-4GB/dp/B000T9251O
The "old" card was a relatively new (~ 1 year) SanDisk card:
https://www.amazon.com/SanDisk-Compact-Frustration-Free-Packaging-SDCFHS-004G-AFFP/dp/B00GHBBJUG/
So I'm more convinced than ever that this has noting to do with "bad CF cards". I also find it hard to believe that a bad or slow CF card would produce an error like that (complaining that a SQL database was malformed.) It seems like a legitimate pfSense bug to me.
Given the end-of-life status of pfSense on i386 (not to mention, frankly, my frustration with all the problems I've had with pfSense on this platform and the general attitude I've experienced that the pfSense devs don't feel that any of it is on them), I'm not going to bother filing a bug report, I'm just going to move on. I wanted to post my results here though to let everyone know what my test results were.
Thanks to everyone that responded and helped out with this, it's sincerely appreciated!
-
I've noticed the ALIX boards do have solder points for an ATA header adjacent to the CF. Perhaps it would be possible to put something else in them? A hard drive seems like overkill though, actually feels like a step backwards for an embedded system.
I did that in the past and installed a HDD on the pin header.
That works but an ALIX is still a 32bit system and support for 32bit (as well as NanoBSD) is vanishing, though the team announced to give those versions at least security updates for some time if need be.
Haveing said that, running 2.3.3_p1 (on an ALIX) is perfectly fine until there's a future security problem not getting fixed anymore.
I successfully updated some older embedded systems to 2.3.3, but I was lazy and just wrote the image to a spare CF card and uploaded the config backup. Works just fine.
The CF Card is mounted read/write now all the time with the heavy writing being on ram-disk for /var and /tmp. That should sort out some of the hiccups you experience. -
I used dd to write a bit-for-bit copy of my previous 2.3.2 install onto it
If some package database was already corrupted on the first CF card, then it is going to be corrupted on the copy.
I would backup the config from the old card, put a fresh install on the new card, restore the config and proceed from there.the pfSense devs don't feel that any of it is on them
If this [refers to|includes me] then be aware that I am here in a totally voluntary capacity. I have received zero financial reward for anything I have done. I try to give the best information and diagnosis that I can. If that is not good enough, then honestly, tough luck - it is definitely not "on me". I am feeling tired of people taking free help on forums and then throwing it back.
-
I have an ALIX running 2.3.3-p1 and it still chugs along. It's not perfect, but it runs. The hardware was great for its time, but it's past EOL. If it still operates, keep using it.
We intend to support 2.3.x for a year or so after 2.4 releases. You're welcome to keep running 2.3.x as long as you want on there.
NanoBSD upgrades have always worked fine in our testing, and from our customers that have reported issues, most of them were due to faulty CF and the others were connectivity related or in very rare cases, a configuration issue preventing DNS from working during the upgrade.
Even new cards can be faulty, it's the luck of the draw there. We can't fix or code around broken disks. Sandisk is usually reliable and fast, at least the 200X ones I typically use. You have to pay a little more for them but they are worth it: SanDisk SDCFH-004G. But even the best CF is still CF.
