Latest update script failure
-
@cmcdonald said in Latest update script failure:
Tomorrow's build will properly cleanup the pkg cache.
Package cache was cleared, ZFS pool has returned to it’s normal size, and zero install errors logged with today’s build! Nice work!
-
@DefenderLLC Awesome thanks for following up!
-
Mine is failing this morning, apparently on the renaming of the boot environment.
Updating repositories metadata...
Updating pfSense-core repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: . done
Processing entries: . done
pfSense-core repository update completed. 5 packages processed.
Updating pfSense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
pfSense repository update completed. 736 packages processed.
All repositories are up to date.
Setting vital flag on pfSense...done.
Renaming current boot environment from upgrade-upgrade-upgrade-upgrade-upgrade-upgrade-default-20240221223437-20240222100045-20240223161555-20240224222137-20240226110515-20240228113322 to upgrade-upgrade-upgrade-upgrade-upgrade-upgrade-default-20240221223437-20240222100045-20240223161555-20240224222137-20240226110515-20240228113322_previous...failed. -
This has been fixed.
But you need to manually rename the current BE to something more sensible and then try the upgrade again.
-
With latest update I cleared all Boot Environments and updates to latest one with Defer Automatic Reboot and Boot Verification off. After restart I was still in the same Boot Environment as before (default-previous). No prompt (Boot Verification) or anything. After setting the new default Environment (24.03.a.20240301.0357) and rebooting I was stuck with no access. Connecting via Serial to have a look and while booting it was asking for the full path to shell and after Returning (use default) boot was interrupted and prompt was present. pfsense not started at all. Rebooted again and switched back to previous environment. This worked well.
After deleting the upgraded environment I tried with updating from web UI as well as from console, same result. Not sure what happend. Updating to alpha versions worked well before, just now with the changes it is behaving strange.
Might wait for a bit to update again.
-
@boessi One thing I have been doing is renaming each boot environment back to "default" after each successful upgrade and some initial testing.
-
@boessi I'm getting the same results as you are. I'm running on a VM. I'd be interested in knowing how you have it set up
-
@townsenk64 In that case, why not just backup your config file and redeploy to a new VM, upgrade that, then restore your config? It's a safe path forward for testing alphas and betas.
-
How do I change the boot environment name? Can i just call it default and do the upgrade?
-
@behemyth said in Latest update script failure:
How do I change the boot environment name? Can i just call it default and do the upgrade?
I always rename mine back to default post-upgrade:
-
Yeah i got it, but my ZFS storage is almost maxed out now. I'm at 1.1g of 1.2g.
And interestingly, it still says im on an older version, even after downloading the 20240301 image.
24.03-DEVELOPMENT (amd64)
built on Thu Feb 29 22:57:00 EST 2024
FreeBSD 15.0-CURRENTThe system is on the latest version.
Version information updated at Fri Mar 1 12:42:27 EST 202
-
@behemyth Just delete the boot environment that's no longer needed. That should free up your space that will allow to upgrade moving forward. Today's build actually clears the package cache.
-
New renaming logic has been added that is more elegant.
Now we rename the current BE as "name_timestamp" and then name the new boot environment "name".
If you defer the reboot and decide to delete the upgraded BE we will rename the current back from "name_timestamp" to "name".
If the upgrade fails we do delete the failed BE and rename the current back to "name" automatically
It's pretty elegant
-
@cmcdonald said in Latest update script failure:
New renaming logic has been added that is more elegant.
Now we rename the current BE as "name_timestamp" and then name the new boot environment "name".
If you defer the reboot and decide to delete the upgraded BE we will rename the current back from "name_timestamp" to "name".
If the upgrade fails we do delete the failed BE and rename the current back to "name" automatically
It's pretty elegant
I noticed this morning and like it. :)
-
@DefenderLLC I did redeploy a new VM. No luck with that either. Generic 2.7.2 install & upgrade to 23.09.1 without issue.
but it continues to fail to boot after upgrading to the 24.x dev build. -
I will test upgrades from 23.09.
-
@cmcdonald I am stuck on 24.03-DEVELOPMENT (amd64)
built on Tue Feb 13 1:00:00 EST 2024
FreeBSD 15.0-CURRENTwhen reboot it hangs looking for path
-
@grandrivers same, rolled back to prev env for now
-
@cmcdonald with latest version (24.03.a.20240302.0116) I got following error while booting into the new environment. Sorry for the screenshot, will log proper output into logfile next time.
-
Roll back and delete the upgraded boot environment.
Enter the command:
touch /verbose_rcYou can use Diagnostics > Command Prompt page for this.
Now perform the upgrade again.
This file will enable more verbose ouput and should tell us exactly what command is failing
