Latest update script failure
-
@behemyth I think that's by design since you have to verify the new boot environment on next boot before it automatically reverts back to previous boot environment. Despite the naming convention changing, I think this is a great new feature. It's not something you would need to rename very often unless you're installing the nightly snapshots.
-
We could certainly clean up the name post upgrade / verification. This was discussed last week internally
-
@cmcdonald Even though it's an extra post-install manual step, I kind of like it this way with the new safely verification feature. I didn't like it at first, but it makes sense why you did it this way. You know how it is though - people generally don't like change.
-
I'm stuck at version 24.03.a.20240215.0600, each time I try to do the upgrade it just reboots to the same version. Do I need to do a manual step? It looks like it's creating a boot environment but will not boot into it. Should I manually boot into the new environment?
-
@boessi You have to "verify" it within a few minutes or it will revert to the previous boot environment. This is a new safety feature. You will see the prompt after you logon after the upgrade and reboot.
-
That is manual verification which can be enabled/disabled in Update Settings.
You can also defer the reboot entirely so it won't automatically reboot after completing the upgrade.
-
@cmcdonald Hmm I don't get this prompt, lets check if I can find the settings option
EDIT: Manually boot into the 0226 environmet also just reverts back to 0215, no option and no prompt
-
@boessi ok setting the boot environment not just for next boot but setting it as new default looks like it was now booting correctly into new version
-
FYI, I'm still seeing this error during the last week or two daily updates, but it still doesn't seem to impact the upgrade; however, my disk usage grows after each upgrade even after deleting the previous boot environment. For the past year or two, my 6 100 MAX ZFS pool has maintained a very consistent 2.5GB worth of space, but now it's grown another gig since installing each 24.03 nightly snapshots - and again I delete the previous boot environment after each successful upgrade and testing as well as clear all system logs.
[1/7] Fetching pfSense-base-24.03.a.20240229.0246.pkg: .......... done [2/7] Fetching snort-2.9.20_8.pkg: .......... done [3/7] Fetching pfSense-24.03.a.20240229.0246.pkg: .......... done [4/7] Fetching pfSense-boot-24.03.a.20240229.0246.pkg: .......... done [5/7] Fetching pfSense-repo-24.03.a.20240229.0246.pkg: . done [6/7] Fetching pfSense-default-config-serial-24.03.a.20240229.0246.pkg: . done [7/7] Fetching pfSense-kernel-pfSense-24.03.a.20240229.0246.pkg: .......... done Checking integrity... done (0 conflicting) [1/7] Upgrading pfSense-boot from 24.03.a.20240228.0600 to 24.03.a.20240229.0246... ******[1/7] Extracting pfSense-boot-24.03.a.20240229.0246: .......... done No such file or directory****** -
This is a good catch, my on-board storage is almost 50% used now, I don't ever remember seeing it this high.
-
Tomorrow's build will properly cleanup the pkg cache.
-
@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?
