[code sync] Merge code from sonic-net/sonic-buildimage:202511 to 202511_azd#2273
Merged
mssonicbld merged 37 commits intoMay 12, 2026
Merged
Conversation
Collaborator
mssonicbld
commented
May 11, 2026
mssonicbld
commented
…vices (#27179) Why I did it: In SAI 14.0.12 based image, programming errors seen while programming lossy PGs of BUFFER_PG. `ERR syncd#syncd: [none] SAI_API_BUFFER:brcm_sai_set_ingress_priority_group_attribute_cmn:501 PG Shared Limit Set failed with error Invalid parameter (0xfffffffc).` How I did it: Total SAI buffer availability has come down in SAI 14.0.12 when compared to SAI 13.2. Adjusted the buffer size to an acceptable level. Changes are made in the BALANCED directory to ensure test sanity. How to verify it: Tuned the SONIC buffer config and verified no programming errors seen. <!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md CODE_OF_CONDUCT.md LICENSE README.md SECURITY.md SUPPORT.md azure-pipelines failure_prs.log scripts skip_prs.log 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 ##### Work item tracking - Microsoft ADO **(number only)**: #### 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 - [ ] 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
#### Why I did it This PR is to add the NH5010 sai_postinit_cmd.soc with the interrupt-ids ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Enabled it by adding those in the platform file sai_postinit_cmd.soc #### How to verify it Run bcmcmd "show int all" to check if those interrupts are enabled. #### 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…(#27184)
closes #27049
#### Why I did it
PR #25504 ("Updating mgmt vrf table id for 4k vrf pool") changed [`files/image_config/interfaces/interfaces.j2`](https://github.com/sonic-net/sonic-buildimage/blob/master/files/image_config/interfaces/interfaces.j2#L12) so the mgmt VRF is now rendered as `vrf-table 6000` (previously `5000`), to align with the companion [sonic-net/sonic-swss#4168](sonic-net/sonic-swss#4168) that increased the user VRF pool to 4096 and moved `MGMT_VRF_TABLE_ID` to 6000.
ifupdown2 was not updated alongside it. Both `3.0.0-1` and `3.9.0` hardcode the upper bound of the allowed VRF table-id range as a class attribute in `ifupdown2/addons/vrf.py`:
```python
class vrf(Addon, moduleBase):
VRF_TABLE_START = 1001
VRF_TABLE_END = 5000
```
The addon reads optional overrides via `policymanager` and falls back to these class attributes:
```python
self.vrf_table_id_end = policymanager.policymanager_api.get_module_globals(
module_name=self.__class__.__name__, attr='vrf-table-id-end'
)
if not self.vrf_table_id_end:
self.vrf_table_id_end = self.VRF_TABLE_END
```
When `interfaces-config.service` runs `ifreload` after `mgmtVrfEnabled` flips to `true`, the addon evaluates the explicit `vrf-table 6000` directive against `[1001, 5000]`, rejects it, and emits:
```
networking[*]: error: <iface>: vrf table id 6000 out of reserved range [1001,5000]
```
The kernel mgmt VRF netdev is never created. The route adds in the mgmt block of `interfaces.j2` then all fail with `Device does not exist` / `Nexthop has invalid gateway`, and management connectivity drops on every `config reload` after enabling mgmt VRF.
##### Work item tracking
- Microsoft ADO **(number only)**:
#### How I did it
ifupdown2's `policymanager` checks `/etc/network/ifupdown2/policy.d/*.json` for module overrides before falling back to the hardcoded class attributes. Adding a `"vrf"` block to the policy file SONiC already ships ([`files/dhcp/ifupdown2_policy.json`](https://github.com/sonic-net/sonic-buildimage/blob/master/files/dhcp/ifupdown2_policy.json)) raises `vrf_table_id_end` to 6000 at runtime, so `vrf.py`'s validation `int(vrf_table) > self.vrf_table_id_end` becomes `6000 > 6000` (False) and the table id is accepted.
```diff
--- a/files/dhcp/ifupdown2_policy.json
+++ b/files/dhcp/ifupdown2_policy.json
@@ -8,5 +8,10 @@
"dhcp6-duid" : "LL"
}
}
+ },
+ "vrf" : {
+ "module_globals" : {
+ "vrf-table-id-end" : 6000
+ }
}
}
```
Only the upper bound is overridden; the lower bound (`1001`) is unchanged so the hardcoded `VRF_TABLE_START` default is correct as-is.
#### How to verify it
##### Minimal verification (ifupdown2 only, no SONiC required)
The simplest possible verification — no `CONFIG_DB`, no `config reload`, no service restart. Just `ifup` reading a one-line iface stanza, exercising the exact `vrf.py` addon code path that gets called during a real `config reload`.
Without this PR (hardcoded `VRF_TABLE_END = 5000`):
```
$ sudo bash -c 'cat > /etc/network/interfaces.d/test-vrf-table.intf <<EOF
auto test-vrf
iface test-vrf
vrf-table 6000
EOF'
$ sudo ifup test-vrf
error: test-vrf: vrf table id 6000 out of reserved range [1001,5000]
$ ip -d link show test-vrf
Device "test-vrf" does not exist.
$ ip vrf show
Name Table
-----------------------
No VRF has been configured
```
With this PR (policy override raises range to 6000):
```
$ sudo ifup test-vrf
$ ip -d link show test-vrf
160: test-vrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 86:81:7b:40:e6:0d brd ff:ff:ff:ff:ff:ff promiscuity 0 allmulti 0 minmtu 1280 maxmtu 65575
vrf table 6000 ...
$ ip vrf show
Name Table
-----------------------
test-vrf 6000
# cleanup:
$ sudo ifdown test-vrf
$ sudo rm /etc/network/interfaces.d/test-vrf-table.intf
```
##### Before this fix (broken state)
On any image built from `master` at or after [`cdb7a13186`](sonic-net/sonic-buildimage@cdb7a13186) (PR #25504), without this PR applied — run from the DUT console, since SSH from elsewhere will time out after the reload:
```
admin@dut:~$ sudo sonic-db-cli CONFIG_DB hset "MGMT_VRF_CONFIG|vrf_global" mgmtVrfEnabled true
admin@dut:~$ sudo config save -y && sudo config reload -y -f
... (reload completes) ...
admin@dut:~$ ip -d link show type vrf
(empty — no mgmt netdev was created)
admin@dut:~$ ip vrf show
Name Table
-----------------------
No VRF has been configured
admin@dut:~$ ip -4 route show table 6000
(empty — no default route, no connected route)
admin@dut:~$ ip -4 rule show | grep 6000
32764: from all to 172.17.0.1/24 lookup 6000
32764: from all to 10.11.0.5 lookup 6000
32764: from all to 10.11.0.6 lookup 6000
32765: from 10.250.59.2 lookup 6000
admin@dut:~$ ip -4 route get 8.8.8.8
RTNETLINK answers: Network is unreachable
admin@dut:~$ sudo grep "out of reserved range" /var/log/syslog
networking[*]: error: eth0: mgmt: vrf table id 6000 out of reserved range [1001,5000]
networking[*]: error: mgmt: vrf table id 6000 out of reserved range [1001,5000]
```
Note that the policy rules above appear in `ip rule show` even though the table itself is empty — `ip rule add` does not depend on the table or netdev existing, so `interfaces.j2`'s `up ip rule add ... table 6000` lines run successfully even when the preceding `up ip route add ... table 6000` lines fail with `Device for nexthop is not up`. The rules end up pointing at an empty table 6000.
From a host on the management network:
```
$ ssh admin@<dut-mgmt-ip>
ssh: connect to host <dut-mgmt-ip> port 22: No route to host
```
Recovery from this state requires console access:
`sudo sonic-db-cli CONFIG_DB del "MGMT_VRF_CONFIG|vrf_global" && sudo config save -y && sudo config reload -y -f`.
##### After this fix (expected state)
```
admin@dut:~$ python3 -c "
import sys; sys.path.insert(0, '/usr/share/ifupdown2')
from ifupdown import policymanager
v = policymanager.policymanager_api.get_module_globals(
module_name='vrf', attr='vrf-table-id-end')
print(v, type(v).__name__)"
6000 int
admin@dut:~$ sudo sonic-db-cli CONFIG_DB hset "MGMT_VRF_CONFIG|vrf_global" mgmtVrfEnabled true
admin@dut:~$ sudo config save -y && sudo config reload -y -f
admin@dut:~$ ip -d link show type vrf
1201: mgmt: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether ca:4b:df:c9:11:79 brd ff:ff:ff:ff:ff:ff promiscuity 0 allmulti 0 minmtu 1280 maxmtu 65575
vrf table 6000 addrgenmode eui64 ...
admin@dut:~$ ip vrf show
Name Table
-----------------------
mgmt 6000
admin@dut:~$ ip -4 route show table 6000
default via 10.250.59.1 dev eth0 metric 201
10.250.59.0/24 dev eth0 proto kernel scope link src 10.250.59.2
local 10.250.59.2 dev eth0 proto kernel scope host src 10.250.59.2
broadcast 10.250.59.255 dev eth0 proto kernel scope link src 10.250.59.2
127.0.0.0/16 dev lo-m proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo-m proto kernel scope host src 127.0.0.1
broadcast 127.0.255.255 dev lo-m proto kernel scope link src 127.0.0.1
admin@dut:~$ ip -4 rule show
1000: from all lookup [l3mdev-table]
1001: from all lookup local
32764: from all to 172.17.0.1/24 lookup mgmt
32764: from all to 10.11.0.5 lookup mgmt
32764: from all to 10.11.0.6 lookup mgmt
32765: from 10.250.59.2 lookup mgmt
32766: from all lookup main
32767: from all lookup default
admin@dut:~$ cat /etc/iproute2/rt_tables.d/ifupdown2_vrf_map.conf
# This file is autogenerated by ifupdown2.
# It contains the vrf name to table mapping.
# Reserved table range 1001 6000
6000 mgmt
admin@dut:~$ sudo grep -E "out of reserved range|cannot be interpreted as an integer" /var/log/syslog
(no matches)
```
Note how `ip rule show` now lists the same policy rules as in the broken case but with `lookup mgmt` instead of `lookup 6000`: ifupdown2 has registered the symbolic name in `/etc/iproute2/rt_tables.d/ifupdown2_vrf_map.conf` and the kernel renders the rule output by name. The kernel-installed `1000: from all lookup [l3mdev-table]` rule is what dispatches eth0 traffic into the mgmt VRF (since eth0 has `master mgmt`).
From a host on the management network — SSH stays usable across the reload (modulo a brief flap during eth0 re-binding):
```
$ ssh admin@<dut-mgmt-ip>
admin@<dut-mgmt-ip>:~$
```
#### Which release branch to backport (provide reason below if selected)
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [x] 202511 — affected by #25504 cherry-pick (#26410). Same fix applies.
#### Tested branch (Please provide the tested image version)
- [ ] master
#### Description for the changelog
`[ifupdown2]` Allow mgmt VRF table id 6000 by setting `vrf-table-id-end` policy in `ifupdown2_policy.json`, restoring mgmt VRF setup that PR #25504 broke when it raised the table id past ifupdown2's hardcoded `VRF_TABLE_END = 5000`.
#### Link to config_db schema for YANG module changes
N/A — no schema change.
#### A picture of a cute animal (not mandatory but encouraged)
🦦
Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
…lly (#27195) #### Why I did it src/sonic-gnmi ``` * cf59a79 - (HEAD -> 202511, origin/202511) [202511] Fix too_many_pings + ARM64 CI + DPU proxy OS.Verify/Activate (Azure#662) (9 hours ago) [rookie-who] ``` #### How I did it #### How to verify it #### Description for the changelog
…lly (#27196) #### Why I did it src/sonic-swss ``` * ebe29ff5 - (HEAD -> 202511, origin/202511) Decrease log severity from ERR to WARN for non-existing ICMP session (#4549) (5 hours ago) [mssonicbld] * fcbf10fc - Increase Vrf pool to 4k (#4168) (#4393) (9 hours ago) [Yash Pandit] ``` #### How I did it #### How to verify it #### Description for the changelog
… startup (#27197) #### Why I did it Backport the upstream FRR fix [FRRouting/frr#20622](FRRouting/frr#20622) ("bgpd: Fix suppress-fib-pending config race condition on startup") into SONiC as a patch on `src/sonic-frr`. Without this fix, `bgpd` has a startup race where a `bgp suppress-fib-pending` configuration applied before the `bgpd` ↔ `zebra` connection is established silently fails to register for Zebra route status notifications. The consequences in SONiC are: - Routes that are already installed and offloaded in the FIB stay marked `fibPending: true` inside `bgpd`. - Those routes are never advertised to eBGP peers, causing traffic loss. - The bad state persists across `clear bgp …` / soft-reconfig attempts and across toggling `suppress-fib-pending` off and on, because `bgpd`'s internal flag and its registration with Zebra are out of sync. Upstream PR [FRRouting/frr#20622](FRRouting/frr#20622) was merged on 2026-02-10; This is to fix the issue before the next FRR Release. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Added the upstream commit as a new patch in `src/sonic-frr/patch/`: - `0106-bgpd-Fix-suppress-fib-pending-config-race-condition.patch` — cherry-pick of [FRRouting/frr#20622](FRRouting/frr#20622) (commit `6bbfb4361e`). #### How to verify it 1. Build a SONiC image with this change and install it on a switch. 2. Reproduce the original ordering that triggered the bug — e.g. a fresh boot with BGP + `bgp suppress-fib-pending` configured, or `config save` followed by `config reload` on a BGP-enabled topology. 3. Bring up BGP sessions with upstream and downstream peers and inject IPv6 routes from upstream. 4. Confirm: - `show bgp ipv6 <prefix>` no longer shows `fibPending: true` for routes that are installed/offloaded in the kernel FIB. - The routes are advertised to downstream eBGP peers. - With `debug bgp zebra`, the new `OP_DEFERRED` / `RETRY Executing deferred ...` log lines appear when the config is applied before Zebra is up, and the retry fires on Zebra connect. 5. Verify the normal case (config applied after Zebra is connected) is unchanged — routes clear `fibPending` and get advertised as before. In internal CI we ran the BGP route-advertisement and TSA-after-`config reload` scenarios that previously reproduced the bug at 100% on master, and confirmed they pass with the patch applied (all route-advertisement asserts passing, no `fibPending`-stuck routes observed). #### A picture of a cute animal (not mandatory but encouraged) <img width="768" height="1024" alt="EA929C24-D3C9-4463-AC7F-EEE412DFFD70_1_105_c" src="https://github.com/user-attachments/assets/bea84790-796f-406e-b451-0e4770813128" /> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
Move dpu-udev-manager from smartswitch/ to platform/mellanox/udev-manager/ and rename units to udev-manager (script + systemd service). Install udev-manager from the new paths in sonic_debian_extension.j2. Add mgmt_interfaces map with eth0 PCI bus for x86_64-nvidia_sn4280-r0 platform.json for stable management netdev naming. Signed-off-by: Oleksandr Ivantsiv <oivantsiv@nvidia.com>
Install python3-ijson Debian package to provide the fast yajl2_c backend for streaming JSON parsing. Relax ijson version pins from ==3.2.3 to >=3.2.3 in sonic-yang-mgmt and sonic-yang-models to allow the Debian package (3.4.0) to satisfy the dependency. This is a prerequisite for sonic-utilities route_check.py to use ijson streaming for improved performance on large route tables. Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Cherry-pick of: sonic-net/sonic-buildimage#25731 Signed-off-by: Nathan Wolfe <nwolfe@arista.com>
…lly (#27214) #### Why I did it src/sonic-swss ``` * 55635b81 - (HEAD -> 202511, origin/202511) Revert "[FC] Set FC delay in command line parameters (#3814)" (#4480) (3 hours ago) [Nazarii Hnydyn] ``` #### How I did it #### How to verify it #### Description for the changelog
…atically (#27216) #### Why I did it src/sonic-utilities ``` * b753f1a8 - (HEAD -> 202511, origin/202511) Showtech collection for gearbox (#4305) (#4523) (2 hours ago) [arpit-nexthop] * fc5a26ee - [sfputil] Gracefully handle missing/invalid info for 'sfputil show eeprom' (#4524) (6 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
Cherry-pick of sonic-net/sonic-buildimage#27093 to 202511 branch. Patch renumbered from 0108 to 0107 to match 202511 series. Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>
…8.3438 (#27127)" (#27204) This reverts commit c676261. Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
…utomatically (#27213) #### Why I did it src/sonic-host-services ``` * 918b502 - (HEAD -> 202511, origin/202511) [caclmgrd]: Skip empty ACL tables (Azure#381) (6 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
<!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md CODE_OF_CONDUCT.md LICENSE README.md SECURITY.md SUPPORT.md azure-pipelines failure_prs.log scripts skip_prs.log 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 We saw Ansible error "A worker was found in a dead state" on multiple test cases after ptf 0.12.0 release Fixes #27183 ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Use the fixed 0.10.0 ptf version in docker-sonic-mgmt #### How to verify it Verify it on acl/test_stress_acl.py <!-- 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) 202511 <!-- - Please provide tested image version - e.g. - [x] 20201231.100 --> - [ ] <!-- image version 1 --> - [ ] <!-- image version 2 --> #### Description for the changelog PTF 0.12.0 was released on 2026/05/02 and caused regression in multiple tests with failure: A worker was found in a dead state Fix it by using the last ptf version 0.10.0 in docker-sonic-mgmt <!-- 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…he global convention /etc/sonic/pending_config_initialization (#27239) #### Why I did it The marker file `pending_config_initialization` is used to track whether SONiC needs to run config initialization (e.g., apply minigraph or YANG default) on the next boot. After sonic-net/sonic-buildimage#25215, the original file `/tmp/pending_config_initialization` is renamed to '/etc/sonic/pending_config_initialization' Most of the `/tmp/pending_config_initialization` has been updated #25215 , raising this PR to update the 2 remaining ones, the two remaining ones are noticed by me during the investigation of issue sonic-net/sonic-buildimage#27131 , but not functional related. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it In `files/image_config/config-setup/config-setup`, replaced the two stale `/tmp/...` paths with the conventional `/etc/sonic/...` path: ```diff do_config_initialization() ... - rm -f /tmp/pending_config_initialization + rm -f /etc/sonic/pending_config_initialization sonic-db-cli CONFIG_DB SET "CONFIG_DB_INITIALIZED" "1" return 0 boot_config() ... sonic-db-cli CONFIG_DB SET "CONFIG_DB_INITIALIZED" "1" - rm -f /tmp/pending_config_initialization + rm -f /etc/sonic/pending_config_initialization return 0 ``` No other changes — purely a path correction to match the producer (`rc.local`) and the consumer (`docker_image_ctl.j2`). #### How to verify it Simple change, to be covered in the PR testing #### Which release branch to backport (provide reason below if selected) <!-- This is a low-risk path correction; backport candidates can be selected by reviewers if the same bug is observed on a release branch. --> - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 #### Tested branch (Please provide the tested image version) - [ ] - [ ] #### Description for the changelog config-setup: clean up `pending_config_initialization` from `/etc/sonic/` (the convention used by `rc.local` and `docker_image_ctl.j2`) instead of the stale `/tmp/` path. #### Link to config_db schema for YANG module changes N/A — no YANG / config_db schema changes. Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
* Use STATE_DB for transceiver temperature reads Signed-off-by: arpit-nexthop <arpit@nexthop.ai>
… (#27241) This change fixes a permanent boot deadlock on multi-ASIC SONiC master images, where `swss@N` fails `start-pre` and is parked by systemd `StartLimitBurst` for ~12+ minutes per window, indefinitely across reboots. Skip touching `/etc/sonic/pending_config_initialization` in `rc.local`'s first-boot `else` branch **only** when `asic.conf` confirms multi-ASIC (`NUM_ASIC > 1`); fall back to the original behavior in every other case so single-ASIC boot is byte-for-byte unchanged. Tracked in #27131. Validates against sonic-net/sonic-mgmt#24234. #### Why I did it ##### The deadlock chain (4 layers) 1. **`rc.local` first-boot `else` branch (this fix)** — when none of `/host/old_config`, `/host/minigraph.xml`, or `/host/migration/minigraph.xml` exists, `rc.local` blindly creates `/etc/sonic/pending_config_initialization`. **No `NUM_ASIC` guard.** 2. **`docker_image_ctl.j2` `postStartAction()`** (lines 296–340) — when the database container starts, if `pending_config_initialization` exists, it sets `CONFIG_DB_INITIALIZED=0` per namespace and stops there (path A). Without the file it falls through to `SET=0 → migrate → SET=1` (path B). 3. **`config-setup boot_config()`** evaluates branches in this order: 1. `pending_config_migration` handler (no `NUM_ASIC` guard, so multi-ASIC with a minigraph or old_config recovers fine — paths 1/2/3) 2. warm-boot branch — sets `CONFIG_DB_INITIALIZED=1` per namespace 3. **`NUM_ASIC > 1` early-return**, with the comment _"For multi-npu platform we don't support config initialization. Assumption is there should be existing minigraph or config_db from previous image."_ 4. `pending_config_initialization` handler — **never reached on multi-ASIC** 4. **`swss@N.service` startup** — `swss.sh wait_for_database_service` polls `until CONFIG_DB_INITIALIZED == 1`, hits the unit's 90 s `TimeoutStartSec`, fails. Three failures within `StartLimitIntervalSec=1200s` exhaust `StartLimitBurst=3` and the service is parked. ##### Why this only started failing recently Commit [`9a624176`](sonic-net/sonic-buildimage@9a62417) ("Move the pending_config files from /tmp/ to /etc/sonic/", PR #25215, 2026-03-31, master only) moved both pending files from a tmpfs (`/tmp/`) to a persistent disk path (`/etc/sonic/`). Before `9a624176`, the deadlock self-healed: - First boot: `rc.local` creates `/tmp/pending_config_initialization` → `swss@N` fails → operator runs `config load_minigraph` (which sets `CONFIG_DB_INITIALIZED=1`) → device works. - First reboot: `/tmp` is wiped → `rc.local` sees no firsttime flag → no pending file created → `database@N` postStartAction goes path B and sets `CONFIG_DB_INITIALIZED=1` → healthy on every subsequent boot. After `9a624176`, the file persists in `/etc/sonic/`, so every reboot re-deadlocks even though provisioning was completed. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it ```diff elif [ -n "$migration" ] && [ -f /host/migration/minigraph.xml ]; then ... touch /etc/sonic/pending_config_migration else - touch /etc/sonic/pending_config_initialization + # config-setup boot_config() skips do_config_initialization on + # multi-ASIC platforms, so creating pending_config_initialization + # there leaves CONFIG_DB_INITIALIZED stuck at 0 and blocks + # swss@N forever. Source asic.conf to learn NUM_ASIC; if it is + # missing or unparseable the original behavior is preserved. + NUM_ASIC= + ASIC_CONF=/usr/share/sonic/device/$platform/asic.conf + [ -f "$ASIC_CONF" ] && . "$ASIC_CONF" + if [ "$NUM_ASIC" -gt 1 ] 2>/dev/null; then + echo "Multi-ASIC platform detected (NUM_ASIC=$NUM_ASIC), skip creating pending_config_initialization flag file" + else + touch /etc/sonic/pending_config_initialization + fi fi ``` ##### Behavior matrix for the `NUM_ASIC` guard | `NUM_ASIC` value | Action | Rationale | |---|---|---| | (unset / `asic.conf` missing) | `touch` | fallback — preserves original behavior | | `1` | `touch` | confirmed single-ASIC — preserves original | | `0`, `-1`, `2.0`, `abc`, `"1 2"`, ... | `touch` | non-pure-integer → `[ -gt ]` returns `2` to stderr → fallback | | `2`, `4`, `8`, `16`, ... | skip_prs.log | confirmed multi-ASIC — the only case that changes | `2>/dev/null` suppresses the `[ -gt ]` "Illegal number" stderr noise on the non-numeric arm; the failed test still correctly drops into the `else` (touch). ##### Single-ASIC and other multi-ASIC paths are unchanged | Boot path | Single-ASIC | Multi-ASIC | |---|---|---| | 1. `/host/old_config/` exists | `pending_config_migration`, unchanged | `pending_config_migration`, unchanged | | 2. `/host/minigraph.xml` exists | `pending_config_migration`, unchanged | `pending_config_migration`, unchanged | | 3. `/host/migration/minigraph.xml` exists (and `migration=true`) | `pending_config_migration`, unchanged | `pending_config_migration`, unchanged | | 4. nothing above (factory blank) | `pending_config_initialization` (unchanged → factory default config / ZTP) | **(this PR)** no file → `database@N` postStartAction sets `CONFIG_DB_INITIALIZED=1`; redis empty until ZTP/operator provisions | This is precisely the "no pending file" branch already covered by `docker_image_ctl.j2` postStartAction path B, and matches what `config-setup boot_config()` already declares as the design contract for multi-ASIC platforms. #### How to verify it ##### Reproduce the bug (without this fix) On a master multi-ASIC image (e.g. `SONiC.master.1102802-c97e1ce43`) on `vms-kvm-four-asic-t1-lag`: ```sh ls -la /etc/sonic/pending_config_initialization # exists for ns in '' asic0 asic1 asic2 asic3; do [ -z "$ns" ] && redis-cli -n 4 GET CONFIG_DB_INITIALIZED \ || ip netns exec $ns redis-cli -n 4 GET CONFIG_DB_INITIALIZED done # 0 in every namespace systemctl status swss@0 swss@1 swss@2 swss@3 # failed / parked ``` ##### After this PR is applied (or simulated by `rm /etc/sonic/pending_config_initialization && reboot`) `database@N` postStartAction goes path B → all 5 namespaces (host + asic0..3) set `CONFIG_DB_INITIALIZED=1` → `swss@N` starts cleanly. ##### sonic-mgmt regression on `vms-kvm-four-asic-t1-lag` Test: `tests/platform_tests/counterpoll/test_counterpoll_watermark.py::test_counterpoll_queue_watermark_pg_drop`. The test calls `random.choice(["config reload", "switch reboot"])`; only the reboot path exercises this bug because `config reload` internally calls `client.set(CONFIG_DB_INITIALIZED, 1)` per namespace (masking the deadlock). | condition | runs | result | reboot-path duration | |---|---|---|---| | Baseline (no fix) reboot path | 4/4 | **FAIL** — "COUNTERS_DB failed to populate after 180s", `StartLimitBurst` exhausted | 1141–1193 s each | | Baseline (no fix) reload path | 4/4 | PASS (config reload internally SET=1) | normal | | **This PR on DUT, forced reboot path** | **1/1** | **PASS** | **651 scripts skip_prs.log (equivalent to reload) | ##### Static checks - `bash -n files/image_config/platform/rc.local` — passes - `sh -n files/image_config/platform/rc.local` — passes - Logic verified against representative `NUM_ASIC` inputs: empty, `0`, `1`, `2`, `4`, `16`, `abc`, `"1 2"`, `2.0`, `-1`. Only positive integers > 1 take the new skip path; all others fall back to the original `touch`. #### Which release branch to backport (provide reason below if selected) **No backport needed.** The regression was introduced by commit [`9a624176`](sonic-net/sonic-buildimage@9a62417) (PR #25215, 2026-03-31), which is master-only and has not been backported to any release branch. Therefore 202305 / 202311 / 202405 / 202411 / 202505 / 202511 do not contain the bug being fixed. - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 #### Tested branch (Please provide the tested image version) - [x] master — `SONiC.master.1102802-c97e1ce43` on `vms-kvm-four-asic-t1-lag` (`x86_64-kvm_x86_64_4_asic-r0` / `msft_four_asic_vs`) #### Description for the changelog [rc.local] Skip touching `pending_config_initialization` on multi-ASIC platforms (NUM_ASIC>1) to fix `swss@N` `start-pre` deadlock on first boot after PR #25215 made the flag persistent. Single-ASIC behavior is unchanged. Fixes #27131. #### Link to config_db schema for YANG module changes N/A — no schema change. #### A picture of a cute animal (not mandatory but encouraged) 🐹 Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
<!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md CODE_OF_CONDUCT.md LICENSE README.md SECURITY.md SUPPORT.md azure-pipelines failure_prs.log scripts skip_prs.log 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 fixes sonic-net/sonic-buildimage#26789 Each `TeamPortSync` instance keeps five long-lived file descriptors alive: four `libnl` sockets and one `epoll` `fd` opened by `team_alloc()` and `team_init()`. Once the `fd` table grows past `FD_SETSIZE` (1024 in `glibc`), the next unix socket that `teamdctl_connect()` opens inside the constructor - for the per-LAG liveness check - is assigned a fd ≥ 1024. The follow-up `teamdctl_config_get_raw_direct()` call hands that fd to `FD_SET()` inside `cli_usock_wait_recv()`. Under glibc's `_FORTIFY_SOURCE=2`, `FD_SET` expands to `__fdelt_chk()`, which aborts the process with `*** bit out of range 0 - FD_SETSIZE` on `fd_set`. `teamsyncd` dies via `SIGABRT`, and eventually `systemd` cascades the failure into a `teamd` restart. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Added a patch to replace both `FD_SET`/`select()` call sites with `poll()`, which takes raw `fd` numbers and has no `FD_SETSIZE` ceiling. Behavior is preserved end to end: each site waits for read-readiness on a single `fd` with the original timeout (5000 ms in `cli_usock_wait_recv`, non-blocking in `team_check_events`). #### How to verify it Test that were failing with high scale portchannels have been passing on DUTs with the changes. <!-- 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…27243) <!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md CODE_OF_CONDUCT.md LICENSE README.md SECURITY.md SUPPORT.md azure-pipelines failure_prs.log scripts skip_prs.log 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 This PR updates Mellanox platform SAI profiles in device/ to enable consistent forwarding behavior for link-local SIP/DIP traffic across additional SKUs by adding the missing SAI profile key. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Add SAI_NOT_DROP_SIP_DIP_LINK_LOCAL=1 to missing Mellanox SN5600 SKUs (V256, O128). Add SAI_NOT_DROP_SIP_DIP_LINK_LOCAL=1 to missing Mellanox SN4700 SKUs (multiple variants). Add SAI_NOT_DROP_SIP_DIP_LINK_LOCAL=1 to Mellanox SN4600C D24C52. #### How to verify it grep -nRHi "SAI_NOT_DROP_SIP_DIP_LINK_LOCAL" device/mellanox/ | wc -l → 47 <!-- 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 - [ ] 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…er. (#27244) #### Why I did it Dynamic Port Breakout support and enable sff_manager for Nokia-IXR7220D4 platform <!-- 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 Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
#### Why I did it Pensando-Elba dpu doesn't uses rc.local script for migration of config_db and configurations for various services. So have introduced mechanism to do similar via dpu.service during first boot post-installation of new image. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Added first-boot detection to `dpu.init` to handle config migration when switching between SONiC images. On initial boot after upgrade, the script moves backed-up configs and sets a flag for `config-setup.service` to perform database migration. Changes - Detect `/boot/first_boot` marker - Move `/host/old_config` → `/etc/sonic/old_config` - Create `pending_config_migration` flag for config-setup.service - Regenerate SSH host keys if ssh.service is inactive Boot Flow After Image Upgrade ``` ┌──────────────────────────────────────────────────────────────┐ │ sonic-installer install <image> │ │ Backup: /etc/sonic → /host/old_config/ │ │ Create marker: /boot/first_boot │ └─────────────────────────┬────────────────────────────────────┘ │ │ System reboot │ ┌─────────────────────────▼────────────────────────────────────┐ │ dpu.service (dpu.init) │ │ Detect /boot/first_boot → move old_config to /etc/sonic │ │ Touch /etc/sonic/pending_config_migration │ └─────────────────────────┬────────────────────────────────────┘ │ │ After=dpu.service │ ┌─────────────────────────▼────────────────────────────────────┐ │ database.service │ │ Start Redis (empty Config DB) │ └─────────────────────────┬────────────────────────────────────┘ │ │ After=database.service │ ┌─────────────────────────▼────────────────────────────────────┐ │ config-setup.service │ │ Detect pending_config_migration → restore /etc/sonic │ │ Load config: sonic-cfggen -j config_db.json --write-to-db │ │ Migrate schema: db_migrator.py -o migrate │ │ Set CONFIG_DB_INITIALIZED = "1" in Redis │ └─────────────────────────┬────────────────────────────────────┘ │ │ Requires CONFIG_DB_INITIALIZED │ ┌─────────────────────────▼────────────────────────────────────┐ │ swss, syncd, pmon, other services │ │ Boot completes with migrated config │ └────────────────────────────────────────────────────────────── ``` #### How to verify it Did below test: 1. Made changes in configuration ``` root@sonic:/home/admin# config interface ip add Loopback1 11.11.11.11/32 root@sonic:/home/admin# config interface ip add Loopback0 12.12.12.12/32 root@sonic:/home/admin# show ip interfaces Interface Master IPv4 address/mask Admin/Oper BGP Neighbor Neighbor IP ------------- -------- ------------------- ------------ -------------- ------------- Ethernet0 20.0.200.4/28 up/up N/A N/A Loopback0 12.12.12.12/32 up/up N/A N/A Loopback1 11.11.11.11/32 up/up N/A N/A docker0 240.127.1.1/24 up/down N/A N/A eth0-midplane 169.254.200.4/24 up/up N/A N/A lo 127.0.0.1/16 up/up N/A N/A ``` 2. Took backup of config_db. ``` root@sonic:/home/admin# config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json ``` 3. Installation of new image ``` root@sonic:/home/admin# sonic-installer install sonic-pensando-20251104.23.bin -y Installing image SONiC-OS-20251104.23 and setting it as default... Command: bash ./sonic-pensando-20251104.23.bin Removing old SONiC installation /host/image-20251104.11 Installing SONiC to /host/image-20251104.23 Archive: fs.zip creating: /host/image-20251104.23/boot/ inflating: /host/image-20251104.23/boot/elba-asic-psci.dtb inflating: /host/image-20251104.23/boot/elba-asic-psci-mtfuji.dtb inflating: /host/image-20251104.23/boot/config-6.12.41+deb13-sonic-arm64 inflating: /host/image-20251104.23/boot/elba-asic-psci-lipari.dtb inflating: /host/image-20251104.23/boot/vmlinuz-6.12.41+deb13-sonic-arm64 inflating: /host/image-20251104.23/boot/install_file inflating: /host/image-20251104.23/boot/initrd.img-6.12.41+deb13-sonic-arm64 inflating: /host/image-20251104.23/boot/System.map-6.12.41+deb13-sonic-arm64 extracting: /host/image-20251104.23/fs.squashfs . . . . . Installing SONiC in SONiC ONIE Installer: platform: arm64-pensando-r0 onie_platform: arm64-elba-asic-flash128-r0 Command: config-setup backup <========================================= config backup Taking backup of current configuration Command: mkdir -p /tmp/image-20251104.23-fs Command: mount -t squashfs /host/image-20251104.23/fs.squashfs /tmp/image-20251104.23-fs Command: sonic-cfggen -d -y /tmp/image-20251104.23-fs/etc/sonic/sonic_version.yml -t /tmp/image-20251104.23-fs/usr/share/sonic/templates/sonic-environment.j2 Command: umount -r -f /tmp/image-20251104.23-fs . . . umount: /tmp/image-20251104.23-fs: not mounted. Command: rm -rf /tmp/image-20251104.23-fs Command: sync Command: sync Command: sync Command: sleep 3 Done ``` 4. Reboot the system. On bootup dpu.service will check first_boot flag and set migration flag ``` Starting dpu.service - dpu sw... [ 13.457118] ionic_mnic: loading out-of-tree module taints kernel. [ 13.463264] ionic_mnic: module verification failed: signature and/or required key missing - tainting kernel [ 13.480617] ionic Pensando Ethernet NIC Driver, ver 201803.01-10231-gb7d486895 . . . python3 -m pip install /usr/share/sonic/device/arm64-elba-asic-flash128-r0/sonic_platform-1.0-py3-none-any.whl Debian GNU/Linux 13 sonic ttyS0 sonic login: [ 18.491547] cgroup: Unknown subsys name 'memory' [ 18.496468] cgroup: Unknown subsys name 'cpuset' [ 18.668254] running_store: kpcimgr will begin running on port 0 [ 20.794076] First boot detected: migrating old configuration <======================= change First boot detected: migrating old configuration [ 20.989425] Configuration migration will be handled by config-setup.service Configuration migration will be handled by config-setup.service [ 21.004624] Waiting for interface eth0-midplane to be created by polaris container... Waiting for interface eth0-midplane to be created by polaris container... ``` 5. config-setup.service will take care of migration ``` root@sonic:/home/admin# cat /var/log/syslog | grep -i --text config-setup 2026-04-23T06:12:40.023358+00:00 sonic dpu[2464]: Configuration migration will be handled by config-setup.service 2026-04-23T06:12:40.023358+00:00 sonic dpu[2464]: Configuration migration will be handled by config-setup.service 2026-04-23T06:13:01.697462+00:00 sonic systemd[1]: Starting config-setup.service - Config initialization and migration service... 2026-04-23T06:13:01.697462+00:00 sonic systemd[1]: Starting config-setup.service - Config initialization and migration service... 2026-04-23T06:13:02.277960+00:00 sonic config-setup[4423]: Missing SONiC configuration minigraph.xml ... 2026-04-23T06:13:02.277960+00:00 sonic config-setup[4423]: Missing SONiC configuration minigraph.xml ... 2026-04-23T06:13:02.278150+00:00 sonic config-setup[4423]: Copying SONiC configuration snmp.yml ... 2026-04-23T06:13:02.278150+00:00 sonic config-setup[4423]: Copying SONiC configuration snmp.yml ... 2026-04-23T06:13:02.343666+00:00 sonic config-setup[4423]: Missing SONiC configuration acl.json ... 2026-04-23T06:13:02.343778+00:00 sonic config-setup[4423]: Missing SONiC configuration port_config.json ... 2026-04-23T06:13:02.343832+00:00 sonic config-setup[4423]: Copying SONiC configuration frr ... 2026-04-23T06:13:02.343666+00:00 sonic config-setup[4423]: Missing SONiC configuration acl.json ... 2026-04-23T06:13:02.343778+00:00 sonic config-setup[4423]: Missing SONiC configuration port_config.json ... 2026-04-23T06:13:02.343832+00:00 sonic config-setup[4423]: Copying SONiC configuration frr ... 2026-04-23T06:13:02.369384+00:00 sonic config-setup[4423]: Missing SONiC configuration telemetry ... 2026-04-23T06:13:02.369471+00:00 sonic config-setup[4423]: Missing SONiC configuration golden_config_db.json ... 2026-04-23T06:13:02.369384+00:00 sonic config-setup[4423]: Missing SONiC configuration telemetry ... 2026-04-23T06:13:02.369471+00:00 sonic config-setup[4423]: Missing SONiC configuration golden_config_db.json ... 2026-04-23T06:13:02.374445+00:00 sonic config-setup[4423]: Copying SONiC configuration config_db.json ... 2026-04-23T06:13:02.374445+00:00 sonic config-setup[4423]: Copying SONiC configuration config_db.json ... 2026-04-23T06:13:02.378503+00:00 sonic config-setup[4423]: Use config_db.json from old system... <============= change 2026-04-23T06:13:02.378559+00:00 sonic config-setup[4423]: Reloading existing config db... 2026-04-23T06:13:02.378503+00:00 sonic config-setup[4423]: Use config_db.json from old system... 2026-04-23T06:13:02.378559+00:00 sonic config-setup[4423]: Reloading existing config db... ``` 6. verification ``` root@sonic:/home/admin# show ip interfaces Interface Master IPv4 address/mask Admin/Oper BGP Neighbor Neighbor IP ------------- -------- ------------------- ------------ -------------- ------------- Ethernet0 20.0.200.4/28 up/up N/A N/A Loopback0 12.12.12.12/32 up/up N/A N/A Loopback1 11.11.11.11/32 up/up N/A N/A docker0 240.127.1.1/24 up/down N/A N/A eth0-midplane 169.254.200.4/24 up/up N/A N/A lo 127.0.0.1/16 up/up N/A N/A ``` #### 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 --> - [x] SONiC-OS-20251104.23 - [ ] <!-- 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…… (#27255) Fix syslog blocked by caclmgrd catch-all DROP on bridge-mode container dhcp_server is the only container using bridge networking (NetworkMode: default). When control plane ACLs (CACL) are configured, caclmgrd adds a catch-all DROP rule at the end of the iptables INPUT chain, which blocks syslog (UDP 514) traffic from the container to the host rsyslog. Add an iptables ACCEPT rule for UDP 514 during dhcp_server startup to allow syslog traffic through, and remove it on stop. <!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md CODE_OF_CONDUCT.md LICENSE README.md SECURITY.md SUPPORT.md azure-pipelines failure_prs.log scripts skip_prs.log 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 On production MX devices, the `dhcp_server` container is the only container using bridge networking (`NetworkMode: default`). All other containers use host networking. When control plane ACL (CACL) rules are configured in CONFIG_DB (e.g., `SSH_ACCESS_MGFX`, `SNMP_ACCESS_MGFX`, `BMC_ACL_NORTHBOUND` — types `CTRLPLANE` and `BMCDATA`), `caclmgrd` appends a catch-all `iptables -A INPUT -j DROP` at the end of the INPUT chain (line 841 in `caclmgrd`, triggered when `num_ctrl_plane_acl_rules > 0`). This catch-all blocks all traffic not explicitly allowed — including syslog (UDP 514) from the dhcp_server container's bridge network to the host rsyslog. The container sends syslog to the docker0 gateway IP (e.g., `240.127.1.1:514`), which is correctly configured by PR #19303. However, the UDP packet is dropped by the catch-all before reaching rsyslog. Lab devices are unaffected because they have no CACL rules (`num_ctrl_plane_acl_rules == 0`), so the catch-all DROP is never added. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Modified `files/build_templates/docker_image_ctl.j2` to add dhcp_server-specific logic: - **preStartAction()**: Insert `iptables -I INPUT -p udp --dport 514 -j ACCEPT` before the container starts (idempotent — checks with `-C` first) - **stop()**: Remove the rule with `iptables -D` when the container stops #### How to verify it End-to-end test on lab device (Nokia-7215, SONiC.20241110.22): ``` === Step 1: Syslog works before CACL === $ docker exec dhcp_server python3 -c "import syslog; syslog.syslog(syslog.LOG_ERR, 'BEFORE_CACL_99999')" $ sudo grep BEFORE_CACL /var/log/syslog 2026 Apr 7 14:51:55 bjw2-can-7215-1 ERR dhcp_server#-c: BEFORE_CACL_99999 → Delivered ✅ === Step 2: Add CACL rule to trigger catch-all DROP === $ sonic-db-cli CONFIG_DB hmset 'ACL_RULE|SSH_ONLY|RULE_1' 'PACKET_ACTION' 'ACCEPT' 'PRIORITY' '100' 'SRC_IP' '0.0.0.0/0' 'IP_PROTOCOL' '6' 'L4_DST_PORT' '22' $ sudo systemctl restart caclmgrd === Step 3: Verify catch-all DROP appeared === $ sudo iptables -L INPUT -n | tail -1 DROP 0 -- 0.0.0.0/0 0.0.0.0/0 → Catch-all DROP present ✅ === Step 4: Syslog blocked by catch-all === $ docker exec dhcp_server python3 -c "import syslog; syslog.syslog(syslog.LOG_ERR, 'AFTER_CACL_99999')" $ sudo grep AFTER_CACL /var/log/syslog (no output) → Blocked ✅ === Step 5: Apply iptables fix === $ sudo iptables -I INPUT -p udp --dport 514 -j ACCEPT === Step 6: Syslog works after fix === $ docker exec dhcp_server python3 -c "import syslog; syslog.syslog(syslog.LOG_ERR, 'AFTER_FIX_99999')" $ sudo grep AFTER_FIX /var/log/syslog 2026 Apr 7 14:52:55 bjw2-can-7215-1 ERR dhcp_server#-c: AFTER_FIX_99999 → Delivered ✅ ``` <!-- 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 - [x] 202603 #### Tested branch (Please provide the tested image version) <!-- - Please provide tested image version - e.g. - [x] 20201231.100 --> - [x] 20241110.22 - [ ] <!-- 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: --> Fix dhcp_server container syslog being silently dropped on devices with control plane ACLs by adding iptables ACCEPT rule for UDP 514 during container startup. <!-- 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 --> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com> #### A picture of a cute animal (not mandatory but encouraged)
…D automatically (#27263) #### Why I did it src/sonic-platform-daemons ``` * 39f4577 - (HEAD -> 202511, origin/202511) Delete only 'PHYSICAL_ENTITY_INFO' entries that daemon has added (Azure#812) (9 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
…atically (#27265) #### Why I did it src/sonic-snmpagent ``` * 25001e1 - (HEAD -> 202511, origin/202511) rfc2737: check if entry is not empty before accessing it (Azure#374) (9 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
…tically (#27257) #### Why I did it src/sonic-dash-api ``` * f496c13 - (HEAD -> 202511, origin/202511) [action] [PR:65] fix(swig): remove explicit libpython linkage from _utils.so (Azure#66) (5 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
…tomatically (#27261) #### Why I did it src/sonic-linux-kernel ``` * c5625d7 - (HEAD -> 202511, origin/202511) Add a patch for printing the AMD Zen CPU reset reason (Azure#571) (4 hours ago) [mssonicbld] * bb32cfe - Fix apparmor vulnerabilities (QID-45097) (Azure#560) (Azure#567) (10 hours ago) [Saikrishna Arcot] ``` #### How I did it #### How to verify it #### Description for the changelog
…lly (#27267) #### Why I did it src/sonic-swss ``` * 78bf5370 - (HEAD -> 202511, origin/202511) Allow state db to take modified entries made to the tunnel decap table (#4555) (23 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
…utomatically (#27259) #### Why I did it src/sonic-host-services ``` * 8bece5c - (HEAD -> 202511, origin/202511) [featured]: Skip redundant CONFIG_DB writes in sync_feature_scope (Azure#382) (9 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
<!--
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
Hide grub menu so that any noise on console cannot interrupt the boot sequence
##### Work item tracking
- Microsoft ADO **(number only)**:
#### How I did it
Add additional command line argument to hide the grub menu
#### How to verify it
Build an image with this change. reboot the box and see that grub meu is no longer seen
<!--
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
-->
Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
#### A picture of a cute animal (not mandatory but encouraged)
…290) #### Why I did it Upgrade the xgs SAI version to 14.3.0.0.0.0.10.0 to include the following changes: - 14.3.0.0.0.0.10.0: Uplift SONIC-121756 and SONIC-121822 to 14.3 1. RX SNR: treat CPU, loopback, and management ports as not supported (debug log only). Use NUM_ATTR_API_CHK for lane reads. 2. FEC counters: when PHY returns not-found/param/unavail (and port for symbol errors), log at DEBUG instead of ERROR; return codes unchanged. ##### Work item tracking - Microsoft ADO **(number only)**: 37845220 #### How I did it Update the xgs SAI version in sai-xgs.mk file. #### How to verify it Load image on a DUT, all containers and bgp are up and running. #### Which release branch to backport (provide reason below if selected) - [x] 202511 Signed-off-by: zitingguo <zitingguo@microsoft.com> Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
Collaborator
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
[202511] Upgrade SONiC package Versions
Collaborator
Author
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…atically (#27286) #### Why I did it src/sonic-utilities ``` * 9d00815c - (HEAD -> 202511, origin/202511) [202511] Use ijson streaming in route_check.py for large route tables (#4509) (3 days ago) [Deepak Singhal] ``` #### How I did it #### How to verify it #### Description for the changelog
SKU: x86_64-arista_7280r4_32qf_32df This is the sonic-buildimage change that goes along with the sonic-mgmt change: sonic-net/sonic-mgmt#24378 #### Why I did it MSFT requested we increment the port name based on the number of system ports instead of line ports #### How I did it Modified the x86_64-arista_7280r4_32qf_32df HWSKU files for the QSFP-DD ports to increment by 4 instead of 8 #### How to verify it Ran the sonic-mgmt test suite with these changes and noticed no related regressions #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 #### Tested branch (Please provide the tested image version) - [x] 202511 Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
Signed-off-by: saksarav <sakthivadivu.saravanaraj@nokia.com>
Signed-off-by: paprakas <pavan.prakash@nokia.com>
Collaborator
Author
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
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
10 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.