Open alexrallen opened 3 years ago
@sujinmkang FYI
@alexrallen originally it is designed to prevent from another fwutil all if there is already 'fwutil all' ran for a different reboot type. But I agree to allow another 'fwutil all' for different reboot type if the first fwutil all call is for none.
@sujinmkang During testing we discovered that this issue has not been completely resolved (my fault for not catching this during the PR review).
https://github.com/Azure/sonic-utilities/pull/2040 only fixed the case of using --boot none
we also see this issue anytime a firmware install fails.
i.e. If you attempt to install firmwares that can only be installed by a cold reboot but you pass the --boot warm
flag then the install will (correctly) fail and create a fw_au_status file. Any subsequent installation attempts will fail due to the presence of that file. This is not desired behavior as there should not be any user intervention necessary to re-attempt the install with the correct boot type.
Perhaps augment the logic you have added here in the above PR https://github.com/Azure/sonic-utilities/pull/2040/files#diff-241959edd76c39dcd4dfc3a6f07416039c62cc17b9ab1c255e87cd301073e12eR909
@sujinmkang can you please help to provide an update on this issue? Thanks.
Description
When
fwutil update all fw --boot=none
it creates a/var/platform/fw_au_status
which remains even after the firmware is installed. On each subsequent execution offwutil update all
it detects the existence of this file and bails out.This also occurs on all unsuccessful firmware installs, the
fw_au_status
file must be deleted manually to proceed.Steps to reproduce the issue:
platform_components.json
fwutil update all fw --boot=none
fwutil update all fw --boot=warm
Describe the results you received:
Describe the results you expected:
We expect not to have to manually delete
fw_au_status
or at least to have clear instructions to do so in the event a stale file is left over.