[code sync] Merge code from sonic-net/sonic-buildimage:202511 to 202512#2018
Merged
mssonicbld merged 6 commits intoAzure:202512from Feb 27, 2026
Merged
[code sync] Merge code from sonic-net/sonic-buildimage:202511 to 202512#2018mssonicbld merged 6 commits intoAzure:202512from
mssonicbld merged 6 commits intoAzure:202512from
Conversation
Collaborator
mssonicbld
commented
Feb 27, 2026
mssonicbld
commented
<!--
Please make sure you've read and understood our contributing guidelines:
https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md
** Make sure all your commits include a signature generated with `git commit -s` **
If this is a bug fix, make sure your description includes "fixes #xxxx", or
"closes #xxxx" or "resolves #xxxx"
Please provide the following information:
-->
#### Why I did it
To bring in latest fixes from NH for Agera2 PAI
##### Work item tracking
- Microsoft ADO **(35792350)**:
#### How I did it
#### How to verify it
<!--
If PR needs to be backported, then the PR must be tested against the base branch and the earliest backport release branch and provide tested image version on these two branches. For example, if the PR is requested for master, 202211 and 202012, then the requester needs to provide test results on master and 202012.
-->
#### Which release branch to backport (provide reason below if selected)
<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [x] 202511
#### Tested branch (Please provide the tested image version)
<!--
- Please provide tested image version
- e.g.
- [x] 20201231.100
-->
- [ ] <!-- image version 1 -->
- [ ] <!-- image version 2 -->
#### Description for the changelog
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->
<!--
Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
-->
#### Link to config_db schema for YANG module changes
<!--
Provide a link to config_db schema for the table for which YANG model
is defined
Link should point to correct section on https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md
-->
#### A picture of a cute animal (not mandatory but encouraged)
…sent (#25657) ### Description of PR **Summary:** When `config_db.json` is missing but `minigraph.xml` is present, the config-setup boot sequence previously triggered ZTP (if enabled), which generates a minimal config and runs `config reload`. This removes the device management IP, requiring console access to recover. Additionally, during warm boot the config initialization path had no guard — if `config_db.json` was absent, ZTP could still be triggered even though warm boot must preserve the existing running configuration. **Root cause:** 1. `do_config_initialization()` had no awareness of `minigraph.xml`. It only checked for ZTP or factory default, even when a valid minigraph was available on disk. 2. `check_system_warm_boot()` only checked STATE_DB, which may not be available early in the boot sequence. The canonical `SONIC_BOOT_TYPE=warm` in `/proc/cmdline` (used by all other boot-type detection in the codebase) was not checked. 3. `boot_config()` did not skip config initialization during warm boot, allowing ZTP to trigger inappropriately. **Fix (3 changes in `config-setup`):** 1. **`do_config_initialization()`**: Check for `minigraph.xml` at the top of the function, before ZTP/factory-default logic. If minigraph is available, use `reload_minigraph` and return early. This aligns with the pattern already used in `do_config_migration()`. 2. **`check_system_warm_boot()`**: Enhanced to check `/proc/cmdline` for `SONIC_BOOT_TYPE=warm` first (the authoritative source set by warm-reboot scripts), then fall back to STATE_DB for compatibility. This is consistent with `getBootType()` used in `docker_image_ctl.j2`, `syncd_common.sh`, and `watchdog-control.sh`. 3. **`boot_config()`**: Added warm boot guard after config migration — during warm boot, skip config initialization and ZTP entirely. Also added `minigraph.xml` guard on the ZTP restart block so ZTP erase/restart is skipped when minigraph was used. This maintains the config priority order consistent with `do_config_migration()`: `config_db.json` > `minigraph.xml` > ZTP > factory default. **Addresses:** ADO 36697420 — `[202511.08] Config Reload is Run during warm-boot up` ### Type of change - [x] Bug fix - [ ] Configuration change (update something in `files/` or `device/`) ### Back port request - [ ] 202505 - [x] 202511 ### Approach #### What is the motivation for this PR? With ZTP enabled on 202511 images, upgrade path tests that delete `config_db.json` trigger ZTP's fallback behavior. ZTP generates a new config and runs `config reload`, wiping management IP. The device then requires console access to recover. During warm boot this is especially dangerous as it disrupts the warm restart flow. #### How did you do it? 1. Added `minigraph.xml` existence check in `do_config_initialization()` before ZTP/factory-default logic 2. Enhanced `check_system_warm_boot()` to check `/proc/cmdline` for `SONIC_BOOT_TYPE=warm` (consistent with all other boot-type detection in the codebase) 3. Added warm boot guard in `boot_config()` to skip config initialization and ZTP during warm boot 4. Added `minigraph.xml` guard on ZTP restart block in `boot_config()` to avoid unnecessary ZTP erase when minigraph was applied #### How did you verify/test it? Code review and trace of all boot code paths in `config-setup`. The minigraph fix follows the same pattern already used in `do_config_migration()` which correctly prefers minigraph over factory default. The warm boot detection follows the same `/proc/cmdline` pattern used by `docker_image_ctl.j2`, `syncd_common.sh`, and `watchdog-control.sh`.
Signed-off-by: sw-r2d2-bot <sw-r2d2-bot@nvidia.com>
… SAIBuild2511.35.3400.5 (#25702) Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
…atically (#25595) #### Why I did it src/sonic-utilities ``` * ddc241ec - (HEAD -> 202511, origin/202511) [storm-control] Fixed show storm-control interface command display (#4302) (32 hours ago) [mssonicbld] * fbd3f90b - [fast-reboot][cosmetic] Fixed debug/error prints with the correct reboot type (#4286) (5 days ago) [Yair Raviv] * efdffa2a - Added counterpoll CLI support (#4291) (6 days ago) [mssonicbld] * 567ad5b3 - [Smartswitch] Prevent early exit of reboot status (#4287) (6 days ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
Collaborator
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.