[william8545]

Preserve request messages in terminal reboot status so a BMC can correlate a HALT result with its request without changing the gNOI response schema.

Select the HALT completion timeout by device identity. On switch-hosts, require both the reboot process and PMON to stop, as before, and report failure if completion cannot be verified. Keep legacy DPU completion behavior.

Persist the graceful BMC shutdown cause before reporting success and retain it when the next boot reports a BMC power-down cause. Add unit coverage for status correlation, timeout selection, completion errors, and reboot-cause handling.

Notes for review:

• On a switch-host the HALT completion check is tri-state. Completion is confirmed only from the real pmon container state and reboot-process state. A Docker or process-table error during the check is reported as Halt completion check could not be answered and the HALT fails, instead of an errored check reading as "stopped" and publishing success. DPU behavior is unchanged.
• switch_host_halt_services_timeout in platform.json must be a JSON integer greater than 0; any other value falls back to 60 seconds. The legacy DPU reader keeps its value handling.
• The reboot cause is written only when the HALT message carries exactly one [bmc-req:<uuid>] tag, matching the BMC's own acceptance rule, so a cause is never attributed to a request the BMC would not recognize.

This is the host-service portion of BMC graceful shutdown/restart, complementing the BMC daemon changes and the switch-host reboot -p changes. It does not provision management credentials or modify the D-Bus interface.

Verification: git diff --check passed. The listed unit suites pass locally; Azure CI runs them on this PR. Image builds and hardware tests were not run. Run pytest tests/host_modules/reboot_test.py tests/determine-reboot-cause_test.py for the affected unit suites.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[liat-grozovik]

@judyjoseph kindly reminder to review

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

This PR has backport request label(s) for branch(es): msft-202608, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202608: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}

[judyjoseph]

One comment on how this timeout relates to the BMC timeout.

[judyjoseph]

This value bounds the residual completion check after reboot -p exits. It is not independent of the BMC side: the BMC graceful_shutdown_timeout (default 120 s, changeable by CLI on the BMC) has to exceed the pre-shutdown time plus this value, and this value plus the BMC power-off verification has to fit inside the 180 s watchdog armed by scripts/reboot. Nothing here, or on the BMC, checks that relationship at run time. A BMC timeout set too low makes every shutdown end forced with reason deadline even when the host succeeded.

Suggestion: add a comment here stating the constraint, and consider logging the effective value when the check starts so a deadline on the BMC side can be correlated with it. Also, since this is only settable through platform.json, please confirm who is expected to size it per platform (the HLD currently leaves that open).

[william8545]

Done. The docstring states the relationship: this value bounds only the check after reboot -p returns, and the BMC timeout has to outlast request, pre-shutdown, this value and polling for a failed check to keep its reason. The check logs the effective value when it starts, and a rejected platform.json value is logged instead of silently replaced. Nothing checks the pair at run time.

[mssonicbld]

Removed label(s):

• Request for msft-202608 Branch: The matching Tested for msft-202608 Branch label is missing. This requirement also applies to manually added request labels.

This PR requests backports for branch(es): 202608, but is missing required test information.

Update the PR description, not a PR comment:

1. List each requested branch under Backport.
2. After testing on each branch, tick its checkbox (- [x]) under Tested branch. An unchecked box (- [ ]) does not count.
3. Under Test result, start a separate entry with each branch number, followed by its test evidence on the same line or the following lines, such as a test-run link or a summary with logs. A branch number alone, placeholders, and results for another branch do not count.

Example format for the branches above (replace every placeholder with your actual test evidence; only check branches you have tested):

### Backport
202608

### Tested branch
- [x] 202608

### Test result
202608: <link to test results or summary with logs>

Keep this information outside HTML comments (<!-- ... -->) so the app can read it.
After you save the PR description, the app checks it again and adds the matching Tested for <branch> Branch labels first, then the Request for <branch> Branch labels. Request labels remain blocked until their matching tested labels are present.

_{---Powered by SONiC BuildBot}

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).