(Solved) amd64 Install Reports i386
-
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
-
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?
-
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.
-
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.)
-
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!
-
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.
-
Very well, I will register with Redmine today and comment on your "rant" regarding this bug. Thanks for your help! ;D
-
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.
-
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.
-
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.
-
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.