Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    (Solved) amd64 Install Reports i386

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    12 Posts 4 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      ghowey
      last edited by

      First of all and always Thank You for a great opensource project. I have noted an unusual behavior in my pfSense auto upgrades. Having 64bit capable hardware, some time back I decided to make the leap. So I backed up pfSense, did a clean install of pfSense 2.2.1 amd64, and imported the backup. Flawless, all went well with no issues. A short time later 2.2.2 was released, so I invoked auto upgrade to both boxes, again all went well except one minor issue. Now both of my boxes report i386. So I exported a backup, did a clean install of 2.2.2 amd64, and imported the backup. Once again perfect, no issues on either box. Then 2.2.3 was released so I did an auto upgrade to the same. Once again both boxes report i386. Can anyone provide any insight, or is this situation unique to just me?

      Thanks in Advance!

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        When you import a backup from another arch; kindly go to System - Firmware - Updater Settings and select the proper arch explicitly from the "Default Auto Update URLs" dropdown – and click Save.

        P.S. And yeah, it's still same braindead as ever: https://redmine.pfsense.org/issues/4636

        1 Reply Last reply Reply Quote 0
        • G
          ghowey
          last edited by

          Thank You, I did indeed miss that step. So apparently I was auto upgrading to the i386 which I would presume is default. One question, can I invoke auto upgrade from i386 to amd64? Or must I do a clean install?

          1 Reply Last reply Reply Quote 0
          • D
            divsys
            last edited by

            No, auto upgrade across architectures is a sure way to get a hooped install.

            Clean install/restore is the way to get up and running.

            -jfp

            1 Reply Last reply Reply Quote 0
            • D
              doktornotor Banned
              last edited by

              @ghowey:

              One question, can I invoke auto upgrade from i386 to amd64? Or must I do a clean install?

              Hmmm, yes - as you have already noticed. I.e., if you have physical access to the box. It will NOT autoreboot after upgrade. (Also note that your RRD graphs will be hosed and will need to be reset.)

              1 Reply Last reply Reply Quote 0
              • G
                ghowey
                last edited by

                Ah, that would explain why my RRD graphs were hosed after the last auto upgrade. Very well, Thank You for resolving my issue, and excuse my naivety! I will proceed with a clean install and set the specific source for auto upgrades in the future! Thanks!

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by

                  Well, frankly this should not happen. Autoupgrade should NOT ever do a cross-arch upgrade without explicit confirmation and warning people about possible pitfalls… Please, go comment on the above-linked Redmine bug - I feel lonely there with the rants.  :P

                  This GUI design and behaviour needs to get fixed. Long overdue. Really braindead.

                  1 Reply Last reply Reply Quote 0
                  • G
                    ghowey
                    last edited by

                    Very well, I will register with Redmine today and comment on your "rant" regarding this bug. Thanks for your help! ;D

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      @doktornotor:

                      When you import a backup from another arch; kindly go to System - Firmware - Updater Settings and select the proper arch explicitly from the "Default Auto Update URLs" dropdown – and click Save.

                      No need to do that and it could just cause future issues in that case if you switch back again. Leave it to default, which will choose the same architecture you're already running of course. Just uncheck "Use an unofficial server for firmware upgrades", save, and you don't have to worry about it.

                      We'll add validation there in the future to make it refuse switching architecture on auto-update.

                      1 Reply Last reply Reply Quote 0
                      • D
                        doktornotor Banned
                        last edited by

                        If there was no need to do that, we'd not have this thread here. Regarding the invisible unknown default… Sigh. Please, fix the GUI already. It's just incredibly dumb, to put it mildly.

                        1 Reply Last reply Reply Quote 0
                        • C
                          cmb
                          last edited by

                          There is no need to hard code it. If we didn't allow hard coding it at all, this problem wouldn't exist and we wouldn't have this thread, because the default is fine. Yes it needs to be fixed to prevent user-induced foot shooting. But no one should be hard coding it, to avoid this exact issue.

                          1 Reply Last reply Reply Quote 0
                          • D
                            doktornotor Banned
                            last edited by

                            It's your code "hardcoding" it when you select something from dropdown. How's that user-induced?! Users assume the GUI exists for a reason, and have a need to check the settings!

                            Stupidity illustrated:

                            Step 0:

                            
                            $ grep firmwareurl /cf/conf/config.xml
                                                            <firmwareurl>https://updates.pfsense.org/_updaters/amd64</firmwareurl>
                            
                            

                            Step 1:

                            Uncheck, Save, as advised above:

                            
                            $ grep firmwareurl /cf/conf/config.xml
                            $
                            
                            

                            Good that we spared one line in config.xml! To make it more helpful, there's nothing useful visible in the GUI either. ::)

                            Step 2:
                            Select the (recommended) "Current architecture", watch the "Use an unofficial server for firmware upgrades" getting automagically ticked. Click Save.

                            
                            $ grep firmwareurl /cf/conf/config.xml
                                                            <firmwareurl>https://updates.pfsense.org/_updaters/amd64</firmwareurl>
                            
                            

                            Result:
                            We are back to Step 0. Wash, rinse, repeat.  >:( >:( >:(

                            Bonus:
                            I also see this note there:

                            NOTE: When a custom URL is configured, the system will not verify the image has an official digital signature

                            but cannot see that coded anywhere. Sigh.

                            Tell people what they have set (even by default) in the GUI. Instead of leaving it blank – and leaving the config.xml blank as well.

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.