pfSense

Caution, if the config is Upgraded on nanobsd platforms the converted RRD files are not immediately saved to the flash. This means that if the box is powercycled instead of rebooted after a conversion the converted RRD files are lost.

Since the conversion takes a really really long time on a Alix or similar the device is often power cycled while it assumed it hangs (which it isn't). This causes a upgraded config to be saved, so no other attempt will be made. This still leaves you with the old RRD files.

These errors showed up on the upgrade, and are associated with the upgrade process, not trying to display the graphs.

Also, during my tests, the box was never powercycled. It was always shut down, or rebooted, using the GUI.

Cheers.

That's good to know, we'll investigate. We're still not quite sure what's happening, some ipv6 builds seem to hit it more.

OK, I'm no expert on RRD, but have done a little more digging on this.

In 1.2.3, the Traffic and Packet RRDs were populated with 2 values, Ibytes, and Obytes, into 2 data points: "in" and "out".

Now, under 2.0, it appears that you are trying to collect 4 values, I4Pass, I4Block, O4Pass, and O4Block, into 4 data points: "inpass", "outpass", "inblock", and "outblock".

However, the RRD, in 2.0, is the "old" 1.2.3 one, hence the errors above, about trying to set 4 values, when only 2 are expected.

This would also explain the errors trying to display the graph:

Oct 9 22:46:02 pfHacom php: /status_rrd_graph_img.php: Failed to create graph with error code 1, the error is: ERROR: No DS called 'inpass' in '/var/db/rrd/wan-traffic.rrd'/usr/bin/nice -n20 /usr/local/bin/rrdtool graph /tmp/wan-traffic.rrd-8hour.png --start 1318196762 --end 1318225562 --vertical-label "bits/sec" --color SHADEA#eeeeee --color SHADEB#eeeeee --title "`hostname` - WAN :: Traffic - 8 hours - 1 minute average" --height 200 --width 620 DEF:wan-in_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass:AVERAGE DEF:wan-out_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass:AVERAGE DEF:wan-in_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock:AVERAGE DEF:wan-out_bytes_block=/var/db/rrd/wan-traffic.rrd:outblock:AVERAGE CDEF:"wan-in_bits_pass=wan-in_bytes_pass,8,*" CDEF:"wan-out_bits_pass=wan-out_bytes_pass,8,*" CDEF:"wan-in_bits_block=wan-in_bytes_block,8,*" CDEF:"wan-out_bits_block=wan-out_bytes_block,8,*" CDEF:"wan-in_bytes=wan-in_bytes_pass,wan-in_bytes_block,+" CDEF:"wan-out_bytes=wan-out_bytes_pass,wan-out_bytes_bloc

Where the command is looking for the new data points: "inpass", "outpass", "inblock", and "outblock".

So, obviously, to upgrade from 1.2.3 -> 2.0, the traffic and packet RRDs must be updated to the "new" format.

Now, what I don't know, is if there is supposed to be a step in the upgrade, to perform the change or not. If there is, then somehow it was skipped.

If not, then it needs to be in place, for the 1.2.3 RRD to be carried forward to 2.0.

Cheers,
Eddie

In config step x we run the following commands. The only things I can think of is that these have failed.

function upgrade_054_to_055() {
global $config;
global $g;

<snip>

mwexec("$rrdtool tune {$rrddbpath}/{$database} -r in:inpass 2>&1");
mwexec("$rrdtool tune {$rrddbpath}/{$database} -r out:outpass 2>71");

That command renames a datasource in a RRD archive from in to inpass and from out to outpass.
We then create a new empty rrd file, dump the xml from that and then layer the old data over the new rrd so that we fill it with data.

It's a rather cumbersome procedure that can take many minutes on a low power alix.

If you can send the rd databases from 1.2.3 my way I can try a lab upgrade.

Just a FYI in case people want to upgrade their 1.2.3 databases on their 2.0 installs. Executing the following code on the command prompt page will call the required function.

Do not run this on already upgraded databases as that can and will cause data loss. Make sure to download the RRD databases before attempting this.
@
include("upgrade_config.inc");
include("rrd.inc");
include("shaper.inc");

upgrade_054_to_055();@