Status - Monitoring: There was an error loading the Left Y Axis.
-
I've upgraded from 2.2.x to 2.3 to 2.3.1 and the RDD graphs are not longer showing up. When I select Monitoring from the Status menu I just get a message that says:
Error: There was an error loading the Left Y Axis.
How can I clear this error?
Here is a screenshot:
 -
If you don't care about historic data you can just hit "Display Advanced" and then "Reset Graphing Data".
-
If you don't care about historic data you can just hit "Display Advanced" and then "Reset Graphing Data".
Is there a solution that involves maintaining historical data?
-
Is there a chance you accidentally changed architectures at some point on your upgrade path?
edit2: I have better error handling in place now, about to commit.
-
Is there a chance you accidentally changed architectures at some point on your upgrade path?
Not intentionally. I just used the auto upgrade feature.
The host is an ESXi virtual machine so I took a snapshot and cleared the RRD data as you suggested. That has eliminated the error. On this particular host keeping the previous RRD would be nice but isn't essential so I may call it good at this point. However, there appears to be a bug in the upgrade procedure. This is a pretty much "vanilla" system so I'd think the upgrades would be very smooth. Up to this point, they have been.
-
you could try running:
rrdtool info /var/db/rrd/system-processor.rrdin the shell and see if it returns an error (I'd be interested to see what it was).
-
I reverted the VM and ran the command you suggested. That returned:
ERROR: This RRD was created on another architecture
I'm not sure how the architecture changed.
-
Thanks! I'm not sure either…
Just to make sure, you are on 2.3.1 (snapshots) now and not 2.3_1 (2.3 w/ Update 1)?
-
This exact same issue happened to me when I upgraded a month ago. I was running 64 bit v2.2.6, upgraded via the GUI and somehow was upgraded to 32 bit v2.3, which broke my RRD graphs just as the OP described. I did do a backup pre-upgrade, but of course, I forgot to uncheck "Skip RRD data", so I was SOL. I'm wondering why it's checked by default anyway… why wouldn't you want to keep your historical data? Considering it can be used for troubleshooting and capacity planning.... but I suppose that's an entirely different discussion. I'm surprised there's not an option to configure and save what default settings you want.
As more and more of these posts are showing up.... I think it's safe to say that these particular issues (auto upgrades changing architecture on execution) should no longer be considered isolated incidents and the logic for the update/upgrade tool should be revisited.
-
I'm not sure how the architecture changed.
Had a hard coded update URL set to the wrong architecture in the config. At defaults, it won't ever change architecture.
-
This exact same issue happened to me when I upgraded a month ago. I was running 64 bit v2.2.6, upgraded via the GUI and somehow was upgraded to 32 bit v2.3, which broke my RRD graphs just as the OP described. I did do a backup pre-upgrade, but of course, I forgot to uncheck "Skip RRD data", so I was SOL. I'm wondering why it's checked by default anyway… why wouldn't you want to keep your historical data?
Because it takes the config backup from a few KB to a few MB.
As more and more of these posts are showing up…. I think it's safe to say that these particular issues (auto upgrades changing architecture on execution) should no longer be considered isolated incidents and the logic for the update/upgrade tool should be revisited.
They're not, but they're all user-induced. Don't hard code your auto-update URL, and if you do, make sure you do it to the right architecture.
In 2.3+, it's impossible to change architectures inadvertently since the custom firmware URL no longer exists and pkg won't use a different architecture (unless you go to a lot of trouble to manually hack things).
-
They're not, but they're all user-induced. Don't hard code your auto-update URL, and if you do, make sure you do it to the right architecture.
You've mentioned the auto-update URL before, but just to be clear, when you say "Don't hard code your auto-update URL", is that directed towards the end user or the devs? Because in my case, the "auto-update URL" was not touched. OP, can you chime in on whether you changed or modified the "auto-update URL"? While it's possible he did, I suspect his answer will align with mine.
-
@cmb:
Had a hard coded update URL set to the wrong architecture in the config. At defaults, it won't ever change architecture.
I bet that is what happened then. A while back the system started to error out while checking for updates. I then setup an update URL which seemed to be working fine up to this point.
I'm now running the stable release of 2.3_1.
-
Very interesting…. I, however, did not modify any update settings.
-
Very interesting…. I, however, did not modify any update settings.
System>Firmware, Updater Settings tab, you had "Use an unofficial server for firmware upgrades" set and a URL there. Often it's left over from when someone wants to follow snapshots. Then that config is restored to new hardware that's then running 64 bit, and on the next upgrade it obeys your update URL there and switches you to 32 bit.
That setting no longer exists in 2.3, but verify it on other pre-2.3 systems before you upgrade.
It's impossible to change architectures via auto-update if that box isn't checked.
-
@cmb:
Very interesting…. I, however, did not modify any update settings.
System>Firmware, Updater Settings tab, you had "Use an unofficial server for firmware upgrades" set and a URL there. Often it's left over from when someone wants to follow snapshots. Then that config is restored to new hardware that's then running 64 bit, and on the next upgrade it obeys your update URL there and switches you to 32 bit.
That setting no longer exists in 2.3, but verify it on other pre-2.3 systems before you upgrade.
It's impossible to change architectures via auto-update if that box isn't checked.
I've been running PFsense since 2009 on v1.2.3 and can tell you without a shadow of a doubt that I have never upgraded to a Alpha/beta/RC/Dev release ever, so there would've been no reason for the auto-update url to be on anything but default as I only run stable releases.
Your explanation for how this issue could happen is completely rational, understandable and fits in the OP's case…. but I'm just saying if that is indeed what happened, the setting must have been flipped by some other process in the system because the auto-update URL was never modified manually in my case.
