Done: NanoBSD - upgrading with keeping the config - the weird way

robi

OK - in advance I'm letting everybody reading this know that this is a very weird way of upgrading, but for some reasons I'm forced to go this way.

I have several NanoBSD installs running around.
One of them has Asterisk installed and a couple of extra packages and tons of mods in the PHP code and so on.

I upgraded from 2.0.1 to 2.0.3 the rest of the boxes without any issues. I had some PHP code mods on them (like temperature monitoring) and munin-node installed, which I had to re-apply manually after the upgrade. These were no problem to be done.

But: there's this extra one, which is in a strange state: has Asterisk package up and running, but it's not displayed in the package list. (it got stuck this way when we changed hardware, kept the same CF card with the existing config and thought only interface mismatch would arise - turned out that there was some mess with the packages too. Asterisk works, and everyting else, but still there's some mess on it).
Anyways, it is known that Asterisk stores it's config on the OS slice not the config slice, thus an update would kill it completely, even if the package would be reinstalled.

All these things which have to be dealt manually, would generate huge service downtimes - especially on Asterisk side (which takes very long time to install on NanoBSD with atom), but other manually patched stuff too, until they would be restored on the live unit running. And the fear that if something goes wrong, downtimes could increase more.

To avoid this, I'm planning to do it like this:

take a fresh CF card and dd on it a vanilla 2.0.3 image
plug it in a different, spare hardware (totally different from the live one, unfortunately)
use some dummy config just to be able to connect to the box
install the same packages for pfSense and BSD, do the PHP hacks and all the other manual stuff configs etc which are on the old system, verify everything is in the same place as on the live system
in the end take the config.xml, ssh_host_keys, and everyting else from the /conf directory of the live 2.0.1 box and copy them to the newly created 2.0.3 box's CF card
unplug power, and replace the previous CF card with this new one

In theory, this would generate downtime only for the time the system boots up with the new CF card in place. Another advantage would be that I still have the old CF card untouched with the working 2.0.1 version, which if something still went wrong can be swapped back…

Do you think this could work (especially the last two points regarding the config replacement by hammer)?

robi

Bump… nobody?

wallabybob

You might run into a problem due to the system disk being in a different location, e.g. /dev/ad0 on the target system instead of /dev/ad4 on the installation system but, provided you determine the correct location on the target system you should be able to edit /etc/fstab to have the correct value on the new cf before you install it on the target system.

robi

Thanks.

I checked the following and got exactly the same results on both systems:

cat /etc/fstab
/dev/ufs/pfsense0 / ufs ro,sync,noatime 1 1
/dev/ufs/cf /cf ufs ro,sync,noatime 1 1
ls /dev/ad*
/dev/ad0    /dev/ad0s1  /dev/ad0s1a /dev/ad0s2  /dev/ad0s2a /dev/ad0s3

Am I right assuming there's nothing to be done regading the disk location?

wallabybob

Looks like the disk has the same name on both system so you shouldn't have a problem with the disk name.

robi

Guys, this weird method worked!

Before touching the live system I made a quick test on the backup hardware by replacing the config file in the /conf directory and rebooted. As expected, interface mismatch happened, but during boot I fixed that with dummy values of that different hardware to let me in.
I noticed that there were package problems, the config file brought the already broken package list from the live system. I compared the initial dummy config file with the one coming from the live system and copied the XML part referring to the packages from there. Brushed it up a little to keep packages's configs - except NTP which was completely changed during the update.
Afterwards, a new reboot, new interface mismatch - but everything else seemed to work fine.

Today I took the live system down, plugged in the newly created card with the patched config file, booted - et voila! It worked! Apart from having to click Save once in the NTP service settings page, everything worked fine! No interface mismatch or any other errors.

Now I have a fully functional, fresh and up-to-date system, and during the process I had virtually no downtime on any of the services offered by the system.