Restore on new Hardware fails with error

[Starko]

Hello,
we want to replace our main Firewall Hardware with a better one. We now use a "soekris 6501" and want to replace it with a "bytemine appliance 6a16er (based on Axiomtek NA-320R)".
Both appliances use network interfaces with names like em0 em1 em2 etc.

The productive Firewall uses the following pfSense version:

2.0.1-RELEASE (i386) 
built on Mon Dec 12 17:53:52 EST 2011 
FreeBSD 8.1-RELEASE-p6

The new installed 6a16er uses:

2.1.5-RELEASE (i386) 
built on Mon Aug 25 07:44:26 EDT 2014 
FreeBSD 8.3-RELEASE-p16

If I remember it right, the old Firewall uses FreeBSD on a mSATA Card, and the new appliance uses NanoBSD on a 4GB CF Card.

After logging into the webinterface and uploading the XML file through the restore wizzard, I receive the following error message in the browser:

Warning: rename(/cf/conf/rrd.tgz,/cf/conf/backup): Is a directory in /etc/inc/upgrade_config.inc on line 3110 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/upgrade_config.inc:3110) in /usr/local/www/diag_backup.php on line 540

Somebody has an idea why me restore on the new Hardware fails?

[phil.davis]

That line 3110 was fixed after 2.1.5 was released: https://github.com/pfsense/pfsense/commit/4045cf1efd15e9cbf88b0e8b3e27428b2dfb3e1e

You should be able to:

1. Reset the 2.1.5 system to factory defaults
2. Edit /etc/inc/upgrade_config.inc and make those 2 additions shown on line 1994 and 3110, save.
3. Restore the config from the other box

The RRD data conversion stuff should then run without spitting out errors.

[Starko]

Does the new line havfe to look like this

@rename("{$g['cf_conf_path']}/rrd.tgz", "{$g['cf_conf_path']}/backup/rrd.tgz");

or that

rename("{$g['cf_conf_path']}/rrd.tgz", "{$g['cf_conf_path']}/backup/rrd.tgz");

?

[phil.davis]

The "@" sign at the front does not matter really - that just suppresses potential output.
Adding "/rrd.tgz" to the string at the end is what really counts.
But go with a straight copy from the commit I pointed to.

[Starko]

I tried to changed it through vi like you said, but I'm on NanoBSD with a 4GB CF Card which makes everything read-only. I don't know how to bypass this.

Error: /etc/inc/upgrade_config.inc: Read-only file system.

EDIT: I found the solution on my own: https://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write

[phil.davis]

Easy way is to use the webGUI Diagnostics->Edit File - easy editing, and it automagically switches to RW to do the save.

From command line:

/etc/rc.conf_mount_rw
"vi" or "ee" to your hearts content
/etc/rc.conf_mount_ro

[Starko]

The restore worked now. But I've seen this message on the first start. Do I have to expect any problems, or can I ignore it?

...
Generating RRD graphs...ERROR: Dangling Comment
ERROR: Incompatible file version, detected version . This is not supported by the version 0003 restore tool.

ERROR: Incompatible file version, detected version . This is not supported by the version 0003 restore tool.

ERROR: Incompatible file version, detected version . This is not supported by the version 0003 restore tool.

ERROR: Incompatible file version, detected version . This is not supported by the version 0003 restore tool.

ERROR: Incompatible file version, detected version . This is not supported by the version 0003 restore tool.

done.
Starting syslog...done.
...

[phil.davis]

It is only going to be the old RRD graph data - and from those errors it looks like it is simply not going to load the old data. It will start from scratch again and save new data.
I am a bit surprised, because I thought the upgrade process ran lots of individual steps to convert various versions of things (like RRD data) upwards and should get it right!
But anyway, it is not going to impact the actual functioning of the firewall.

[Starko]

Thank you very much for your help. Everything seems to work fine. We will replace the old hardware sometime in the future.
Any news on when 2.1.6 will be available which includes the bugfix for the restore?