There was an historical thread about how to better understand when Unsafe Updates are necessary (and should be then allowed) here and also here...and from what I read and experienced...Release Notes never started to report if allowing unsafe updates was necessary or not (per platform) for any particular update/upgrade matrix considered.
By the way it's quite interesting the power-cycle requirement of Aruba CX 6400...
-------------------------------------------
Original Message:
Sent: Aug 04, 2025 08:42 AM
From: Jsysmoomin
Subject: Re: AOS-CX Tech Tips: "allow-unsafe-updates"
Hi Richard,
Thanks
It looks like that the allow-non-failsafe-updates feature does not exist in 10.10. - allow-unsafe-updates in 10.10 still required pulling of the power manually for it to apply the updates on the backplane board.
We will need to update to 10.13 to probably get this to work. I will look into moving to 10.13 branch.
Original Message:
Sent: Aug 04, 2025 08:19 AM
From: Richard Litchfield
Subject: Re: AOS-CX Tech Tips: "allow-unsafe-updates"
Today if you want or need to apply additional updates at the ServiceOS level (these are infrequent, but it is good to get them done), follow this process for a Central-managed switch:
bvcore-6300# confbvcore-6300(config)# hpe-anw-central support-modebvcore-6300(config)# allow-unsafe-updates 30This command is deprecated.Please use "allow-non-failsafe-updates" instead.This command will enable non-failsafe updates of programmable devices forthe next 30 minutes. You will first need to wait for all line and fabricmodules to reach the ready state, and then reboot the switch to beginapplying any needed updates. Ensure that the switch will not lose power,be rebooted again, or have any modules removed until all updates havefinished and all line and fabric modules have returned to the ready state.WARNING: Interrupting these updates may make the product unusable!Continue (y/n)? y Non-failsafe updates: allowed (less than 30 minute(s) remaining)
Looks like the new command is allow-non-failsafe-updates !
30 is the number of minutes to allow this to be possible. For the switches with big firmware files, I often set that to 45min if I am pushing it out from Central with a reboot. If you prestage the firmware and reboot later, 15/20min has always worked for me.
Push the firmware from Central along with the reboot when finished.
Work is underway to enable an API for this, and once that is released, no CLI interaction will be required.
I use a similar process for VSX pairs:
- re-stage the firmware on both members first with Central
- from the CLI, allow-non-failsafe-updates on both members
- then run the vsx-update from the CLI to update them both in the scripted process.
------------------------------
Richard Litchfield
Airheads MVP 2020, 2021, 2022
Original Message:
Sent: Aug 01, 2025 09:46 AM
From: Jsysmoomin
Subject: Re: AOS-CX Tech Tips: "allow-unsafe-updates"
Hi Matthew,
Did anything happen with this?
We have just gone to 10.10.1150 and have had to restart our 6405 twice by pulling the power out for it to update.
Also your support at TAC had no idea this was a thing. So I am glad I have found this thread that solved the issue.
Original Message:
Sent: Oct 26, 2020 11:54 AM
From: Matthew_Fern
Subject: Re: AOS-CX Tech Tips: "allow-unsafe-updates"
This is, to my knowledge, unique to the 6405 and 6410 - infrequently, component firmware updates on these models require a full power cycle of the switch chassis to complete the update process.
I am feeding this back to engineering to determine if there is a plan to eliminate this requirement for future updates, and to recommend that the power-cycle requirement is clearly documented where applicable.