Can I fix upgrade to wrong arch before reboot?
-
I put the wrong upgrade url into the manual update url for the latest 2.2 release candidate. I used the amd 64 link on accident when the CPU does not support that.
The firewall has not rebooted yet after about a day sitting at an upgrade is in progress. From what I recall that is normal if you upgrade to a different arch on purpose. This might be a good thing for me. If it reboots it will certainly not boot. The GUI doesn't allow changing the update url (it just says an upgrade is in progress) and the same for the edit file php page. Interestingly the auto upgrade page does work. If I can get the URL changed in the config file and do the upgrade again I wonder if I could update to the i386 build to fix it since the firewall has not rebooted yet.
The console does not allow a shell during the upgrade either so I can't seem to find a way to change the upgrade url and attempt another upgrade. I realize this might not work anyway but it is worth a try if I could get access to the config.xml or allow the page to work to change the upgrade url.
-
Which install type?
It looks bad whatever to be honest. :-\ I've never tried to recover from that situation though.Steve
-
Full install on an axiomtek embedded device using a 2.5" hard drive. It is a pain to get the system apart so I was hoping to not have to disassemble the thing to fix it. I tried the exec.php page and that also says an upgrade in progress so I can't use it.
-
If you can get to a shell prompt (console menu 8, or login by ssh), then look in /var/run/*.dirty
There should be:
/var/run/firmwarelock.dirtyDelete that file, that will clear the GUI from jumping to the "upgrade in progress" page all the time.
If there are are other *.dirty then probably good to delete those also, so the whole system thinks everything is clean (even though it clearly is not).Then you can try another upgrade to an i386 version, cross your fingers and hope!
It will be interesting to see if it survives…
-
Thanks for the info on the file. The problem is I can't get to a shell though. Login via SSH just disconnects after entering username. The console doesn't seem to accept any input right now (enter doesn't even do anything). Caps lock works so I am sure it is not locked up (the firewall works too). The gui doesn't work because of the " An upgrade is currently in progress." message except for the auto upgrade tab that does work but the wrong url is being used.
I was hopeful I could find another way into the console that I am just not thinking about yet or another way to edit the file through the gui (with a post or something).
EDIT: It would be great if the gui would warn you if the arch being installed is different than the existing already installed pfsense arch for people like me :). I have done this twice now in the past 3 years when running betas :).
-
EDIT: It would be great if the gui would warn you if the arch being installed is different than the existing already installed pfsense arch for people like me :). I have done this twice now in the past 3 years when running betas :).
I did this also a few weeks ago. I had upgraded a 64-bit system, then pasted the link to a guy at another site without thinking. His system was an Alix (really 32-bit only). He used my link, and the upgrade all went through on the other slice. But of course the boot died as soon as it tried to execute 64-bit instructions.
-
Problem is all the binaries you need to switch back are now only available in their 64 bit versions, which makes them impossible to execute. Even copying over a minimum set of files to extract the 32 bit version is going to be impossible as the files necessary to copy files or mount a drive are also affected. So you're stuck in a catch 22 there. You'll need to reinstall and restore.
-
Thanks for the info. This is my home system so it's not a big deal. I will just hope for no power outages and plan it for Sunday or Monday night. It is pretty easy to do once I get the hard drive out of the system. Thanks again.
-
His system was an Alix (really 32-bit only). He used my link, and the upgrade all went through on the other slice. But of course the boot died as soon as it tried to execute 64-bit instructions.
Presumably he was running Nano. I assume he could just switch back to the other slice and then upgrade correctly? The boot loader isn't overwritten? If that is the case and you switch from a 64bit install to a 32bit do you end up with a 64bit boot loader? Hmm, never really thought about that before.
Steve
-
Yes, that was an Alix running nanoBSD. A switch back to boot from the old slice brought back 2.1.5 untouched. That is the big benefit of the nanoBSD 2-slice system - you can mess up whatever on the upgrade and then go back really easily.
If the upgrade booted far enough to run the config upgrade scripts, then you might have to put your old config back, depending what features you used that had config changes in the upgrade. But you do not have to remove the media and rewrite a good image on it.