Upgrade problem, AMD64 to i386



  • Hi

    I recently discovered a problem with my pfSense installation. Its running i386 on a new Xeon CPU with 16gigs of ram.
    I positive I installed amd64 with a config restore and i think I've run into this problem:

    http://permalink.gmane.org/gmane.comp.security.firewalls.pfsense.general/5151

    But the thing is, I have a continous chain of RRD data from the whole period, from 30th of May, when I installed and up until now.
    I have confirmed the architecture with binary versions from some old splunk logs, OpenVPN was running amd64 in may and i386 in october.
    I installed 2.1.3 and the first upgrade possible was 26th of june. I should have lost about one month of data.

    Is this even possible? Is there some other explanation or is there some way that my RRD data remained after moving down to i386?

    I'm eager to figure this one out to prevent it from happening again.

    Regards



  • The data is still there, it just can't be read by 32 bit rrdtool. If you upgrade back to 64 bit (after which you'll have to power cycle the system since the 64 bit binaries to reboot won't be able to run), then your RRD data should all "just work" since you'll again have the 64 bit version of rrdtool. That's assuming you haven't hit the "reset RRD data" button, which will delete all that history.


  • Netgate Administrator

    The issue appears to be that there isn't any loss of data when it is expected. I have no explanation for that either other than it was always 32bit and the logs are misleading you somehow.  :-\

    Steve



  • This had happened to one of my routers as well, went from amd64 to i386 during an upgrade – no explanation.



  • @seattle-it:

    This had happened to one of my routers as well, went from amd64 to i386 during an upgrade – no explanation.

    That can only happen one of two ways.

    1. for manual update, you provided it the wrong update file.
    2. for auto update - you manually set the auto-update URL at some point to a URL for i386. Maybe at the time, the config was running on i386, then you restored it to an amd64 install. That doesn't change user-configured auto update URL overrides (nothing does, you set it, we won't touch it). If kept to the default, it'll automatically pull the update for the architecture it's currently running. For systems I've never been on before, I make sure to check the Updater Settings tab before running an auto-update to ensure it's set to use the default URL.


  • Thanks guys, its gotta be the bad upgrade address after restore causing it.
    I still don't get why I didn't lose RRD data, but I'll just write this one off on me not getting the install right in the first place.

    Regards,
    Wish



  • That can only happen one of two ways.

    1. for manual update, you provided it the wrong update file.
    2. for auto update - you manually set the auto-update URL at some point to a URL for i386.

    I had the same issue too. I made auto-update. And i am 101% sure that i ran amd64 on my APU.
    And i did not touch the auto-update url. Must be another, third issue.
    Anyway: why not check and warn if running_Architecture ne update_Architecture ?



  • This just happened to me also.

    Upgraded from 2.2.1 to 2.2.2

    What can one do, to get it back to amd64 - without any risk of corruption ?

    If this is a known issue, that has been discussed for some time now - why has it not been resolved ?





  • @brasilnut:

    What can one do, to get it back to amd64 - without any risk of corruption ?

    For most purposes, upgrade back to 64 bit. Just keep in mind it won't reboot on its own, power cycle when it's finished.

    @brasilnut:

    If this is a known issue, that has been discussed for some time now - why has it not been resolved ?

    Because it's the result of user error, not an actual software problem. If you manually override your update URL at some point, then restore that config to a diff architecture, it'll still have the old architecture hard coded as the update URL. There is a feature request ticket to make the upgrade refuse to continue in this situation that we'll probably implement at some point. Ultimately you should, as the upgrade guide says, check your update URL before auto-updating if you ever changed anything there. And take care when restoring configs to different architecture that you don't have a hard-coded update URL.


  • Banned

    @cmb:

    Ultimately you should, as the upgrade guide says, check your update URL before auto-updating if you ever changed anything there.

    Sorry. This suggestion just does NOT work. Particularly due to the fact that this GUI part is just utterly braindead, as described in this ticket: https://redmine.pfsense.org/issues/4636

    Please, fix it. This is no feature request, this is absolutely basic stuff that just needs to work and not confuse people.



  • :-\

    At no point did I ever change the settings for the update URL.

    :-\



  • Got the system stabilized, and am back to 2.2.1-RELEASE (amd64)

    The dropdown for "Default Auto Update URLs" says "pfSense amd64 stables ubdates (current architecture)"
    Firmware Auto Update URL:  " Use an unofficial server for firmware upgrades" is checked.
    Base URL: https://updates.pfsense.org/_updaters/amd64
    also selcected is: "Allow auto-update firmware images with a missing or invalid digital signature to be used."

    Is it safe now, to "Invoke Auto Upgrade", without causing the architecture to change ?


  • Netgate Administrator

    Yes, you're pointing at the amd64 repo. It's safe.

    Steve