Is it platform specific
generic
Importance or Severity
Critical
Description of the bug
Redfish tests are skipped because the BMC clock differs significantly from the sonic-mgmt runner, even though both are configured to use NTP server and report synchronization.
Observed offsets range from 265 seconds to 43,973 seconds:
BMC clock is 43973s behind sonic-mgmt container
(2026-09-11T18:42:28Z vs 2026-09-11T06:29:35Z).
Investigation findings
A BMC power cycle can initialize the system from stale RTC time. Chrony subsequently selects the configured NTP server, but SONiC disables makestep by default, so large offsets are corrected gradually through slewing.
This is not continuous drift while fully synchronized. It is a large post-power-cycle initial offset that is not corrected quickly enough before Redfish begins.
Related
#27908
#28050
Steps to Reproduce
- Configure both the sonic-mgmt test server and BMC DUT to use the same NTP server.
- Confirm both sides report NTP synchronization.
- Run the BMC test suite
Actual Behavior and Expected Behavior
The BMC clock diverges significantly from the sonic-mgmt runner despite both sides reporting NTP synchronization. Observed differences range from several minutes to over 12 hours
This causes Redfish TLS certificates to appear not yet valid on the BMC.
When both systems use the same NTP source and report synchronized, their clocks should remain closely aligned and Redfish certificate validation should succeed.
Relevant log output
Output of show version, show techsupport
Attach files (if any)
No response
Is it platform specific
generic
Importance or Severity
Critical
Description of the bug
Redfish tests are skipped because the BMC clock differs significantly from the sonic-mgmt runner, even though both are configured to use NTP server and report synchronization.
Observed offsets range from 265 seconds to 43,973 seconds:
Investigation findings
A BMC power cycle can initialize the system from stale RTC time. Chrony subsequently selects the configured NTP server, but SONiC disables makestep by default, so large offsets are corrected gradually through slewing.
This is not continuous drift while fully synchronized. It is a large post-power-cycle initial offset that is not corrected quickly enough before Redfish begins.
Related
#27908
#28050
Steps to Reproduce
Actual Behavior and Expected Behavior
The BMC clock diverges significantly from the sonic-mgmt runner despite both sides reporting NTP synchronization. Observed differences range from several minutes to over 12 hours
This causes Redfish TLS certificates to appear not yet valid on the BMC.
When both systems use the same NTP source and report synchronized, their clocks should remain closely aligned and Redfish certificate validation should succeed.
Relevant log output
Output of
show version,show techsupportAttach files (if any)
No response