After upgrade 24.03 to 24.11 reboot hangs at start @ 0xffffff....
-
And that is just booting the two BEs? No other changes?
-
Yes.
-
I got it booting into 24.11 using the console upgrade option (lucky number 13).
Had to reboot twice though. After the first reboot the GUI wasn't working (bad request error).
Now it seems to be ok (fingers crossed). -
Hmm, so upgrading via the gui resulted in no boot but upgrading via the CLI succeeded?
There should be no difference between those.
-
@stephenw10 said in After upgrade 24.03 to 24.11 reboot hangs at start @ 0xffffff....:
Hmm, so upgrading via the gui resulted in no boot but upgrading via the CLI succeeded?
There should be no difference between those.
Others upthread had success when they tried it again, so it may have been the retry that did it and not the method. Still doesn't make a lot of sense, but at least seems to be consistently inconsistent.
-
@jimp with the GUI i tried twice with the same outcome. First from home which had me to turn into the office at night to fix it.
-
Successfully upgraded from 24.03 to 24.11 via command line (SSH).
I'd been dreading the unpleasant task of dealing with the previous GUI update failures, but SSH -> Option 13 -> Reboot and back up in ~3min with little trouble.
-
I encountered this exact same problem on a Netgate 4200 (non-MAX).
Tried upgrading from 24.03 to 24.11 in GUI, the update process seems to go smoothly, untill the reboot. After reboot the device does not come back up. So i rushed to the location in the middle of the night, and encountered the Netgate unit unreachable locally, and all 3 lights on the netgate device are lit up (green / purple / blue). Gave the device a hard reset by pulling power, after which it reverts to 24.03, and operated normally again.
I have then tried the update again, with the same exact results. And again, after pulling power, it reverts to 24.03 and continues operation.The only solution that worked was the one offered by @GripePotato , to SSH into the unit and pick lucky number 13 to upgrade the system. The install on the console looks exactly the same as it did in the web GUI, except after rebooting this time the unit did come back up normally and is running the new version 24.11.
I had postponed the update specifically to wait out any possible bugs. For this bug to still exist months after the update's release, without any warning within the web GUI that is fairly egregious if you ask me. Since it completely kills the unit and someone will have to be on site to pull and restore power from the unit. It would be nice if the unit would recognize the failed update and rebooted itself back into the last working system version, as it does when someone pulls power. It also does not help there is no logging that remains after reverting to 24.03, the update log will simply show there is a 24.11 update available. So the cause of the update breaking remains unknown.
For future updates i guess we will have to have someone on site for every netgate firewall after-hours, and only upgrade the netgate units using the SSH console, to ensure netgate does not break anything with the update again like this.
-
I As far as I know we never managed to replicate this. I upgraded 4200s many, many times during testing. And since then thousands have been upgraded in the field.
I still have no idea what could cause this. Upgrading at the console is the same process at the backend.
-
@stephenw10 Interestingly I just has this exact issue with the gui on the 4200 max. Had to drive to location to pull the plug.
I'll leave 24.03 for now until another release.
-
Hmm, default boot config? No BIOS changes?
-
@weebey Hi, as i understood the problem, it seemed to have something to do with the updater when used from the GUI, but from the command line it worked fine. Possibly because i SSH in as 'root' user (the 'admin' account in pfsense) to start the update, and the GUI might run the upgrade process under another user. At least that was the only guess i could make for this strange behavior updating via the gui.
So in either case it seemed it was solved by enabling SSH (and enabling the 'admin' account for root access) for the unit in the GUI, SSH in as root, and update using option 13.
The output will mirror the upgrade process as printed in the GUI, but for some reason the unit rebooted normally after updating from the SSH menu, and it continued working normally under the latest version after that. -
@stephenw10 I believe everything was default. A colleague set it up but we don't change boot configs. The only thing I can think of is that I downloaded a the backup config file moments before pressing the update button the GUI.
-
@NetworkTechie Thanks for this feedback. I'll share it with colleagues. I believe that we have several 4200 MAX at multiple sites that will need to be updated soon. At the very least, we know this problem may happen so we may try to update them with your method when someone is on-site.
But to clarify, you believe that SSH with root shell is a safer option than via console port?
-
Upgrading from the local console is always the safest way. That is using the root user. More importantly you will see all the output from upgrade including after the reboot. So if there's some issue with hardware in the new OS version you will see it and be able debug.
