NanoBSB 4GB VGA Upgrade Process Explained
-
My first install (nanobsd 4gb vga) was 2.2.1 so I am still new to pfsense. I just went through the GUI upgrade process (for the first time, ever) to 2.2.2 with no issues. I have a couple of questions based on my experience that would just be helpful for me understanding how it works and what I can expect for future upgrades.
-
It took about 3-5 minutes to upload the 74MB upgrade img file via the GUI firmware updater. Is that typical? I was using Chrome. I saw the status at the bottom of the screen (1%… 5%... 100%... etc) the whole time so I know it was progressing but just seems odd that on my LAN it went (what I feel) was really slow. It also took about a good 3-5 minutes to actually go through the upgrade process when I was observing on the console (from the message /boot/firmware.gz when that came up on the screen to the text that indicated the firewall would be rebooting.) Are each of those 3-5 minute time periods for uploading the upgrade img and actually the upgrade process normal?
-
I've read the Wiki "Upgrade Guide" and "Firmware Updates" but could not find an answer to this question. How exactly does the upgrade process work? Prior to upgrade I was booted to the F1 slice (not entirely sure but pretty sure.) I know there are two slices: F1 and F2 (and a configuration partition as well.) I assume that since I was able to navigate to Internet sites during the upgrade that the actually upgrade process I invoked in the GUI updated the F2 slice (the one I was NOT using prior to updating.) I was observing the console the whole time during the upgrade process. Upon reboot after the console indicating the upgrade was complete and that the firewall was rebooting, I noticed that the F2 slice was the one that was now booting. At this point is the F1 slice now updated to 2.2.2? I guess my question is at what point is the alternate boot slice updated to 2.2.2? And yes, I did confirm that upon reboot when booted into the F2 slice it is now 2.2.2 :)
Hopefully these are fairly simple questions :) Thanks!
-
-
At this point is the F1 slice now updated to 2.2.2?
No, of course not. Would kill the fallback altogether, leaving the two slices pointless. Duplicate is manually (Diagnostics - NanoBSD) when you are sure that everything is working.
-
The upgrade time is quite normal - typical nanoBSD storage like CF card or SD card are quite slow to write. The system has to unpack all the upgrade file and write it to the opposite slice.
While the opposite slice is being prepared the firewall is processing ordinary traffic, so there is no interruption to user service until the actual reboot.
The original slice is left unchanged - so you can easily boot from it if you need to go back.
Once you are happy that the new version is working fine, then use the duplicate slice on the GUI to copy the new, currently running, slice over the old slice. Then you have 2 identical boot slices - like doktornotor said. -
Thanks for very much for the quick replies! All is working on the F2 slice (da0s2 in my case) on 2.2.2. Thus, I was able to navigate to Diagnostics –> NanoBSD and was able to duplicate da0s2 --> da0s1 successfully. Took about 5 minutes or so. After that completed, I went to Diagnostics --> NanoBSD and changed the bootup slice to be da0s1 just to confirm it duplicated successfully. Rebooted. I am now running 2.2.2 on da0s1 (and da0s2 previously) so all is well. Thanks very much!
-
This is a great feature! Its a shame the HD install doesn't have it.
An enhancement could be for an automatic reboot after 1 hour to the previous slice if the upgraded slice is not confirmed as being successful from either the GUI or a CLI prompt. This would be very useful to anyone supporting remote systems as downtime would be limited to 1 hour following a failed upgrade.
-
An enhancement could be for an automatic reboot after 1 hour to the previous slice if the upgraded slice is not confirmed as being successful from either the GUI or a CLI prompt. This would be very useful to anyone supporting remote systems as downtime would be limited to 1 hour following a failed upgrade.
That would be a nice thing, but would only work if the OS on the new slice is actually bootable. I guess that could still catch some application issues, e.g. if the system booted OK but some firewall rules startup/VPN links/road warrior VPN server… did not come up.
If it got some issue booting then any process that monitored things checking to see if success is confirmed by someone/something, would not be running. I can think of 2 cases like this that have happened to me - some dev snapshots that were missing a kernel, and hardware that worked with FreeBSD 8.3 + pfSense 2.1.n but did not boot FreeBSD 10.1 + pfSense 2.2.n - in both these cases the system was sitting at a console boot prompt of some sort and unable to proceed. I always have at home or at my local office an example of every hardware combination that is installed somewhere remotely. Then I can do local upgrades first and know that all my hardware combinations are at least bootable.