Why I did it
Cherry-pick #12009, and fix code conflict.
Fix the dbus-pyhon installation failure when building docker-sonic-vs, caused by the command dbus-run-session not found.
The command "dbus-run-session" should be the new dependency introduced in dbus-python 1.3.2, the old version 1.2.18 does not have the issue.
How I did it
Install the dbus debian package which contains the command dbus-run-session.
It is not a blocking issue on release branches. The release branches with reproducible build feature can avoid such issue in official builds and PR builds, it only block the version upgrade (trying to upgrade from 1.2.18 to 1.3.2).
How to verify it
- Why I did it
Update SDK/FW version - 4.5.2318/2010_2318 to pick up new fixes:
1. Cr space timeout on Hold and Release GW - at warm boot
2. SPC-1 Port in stuck PHY_UP after peer side rebooted
3. memory leak in sx_api_router_ecmp_update_set
- How I did it
update the make file with the new version number
update submodule Switch-SDK-drivers pointer
- How to verify it
run sonic regression
Signed-off-by: Kebo Liu <kebol@nvidia.com>
* [snmpd]: Update to 5.9+dfsg-4+deb11u1 to match Debian version
This brings in some security fixes.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
- Why I did it
This is for the eventual support of multiple architectures for the mellanox platform.
- How I did it
Change the location of the binaries in Switch-SDK-drivers so that the path specifies the target architecture in addition to the target distribution that the debians are built for.
This is the most straightforward way to separate binaries built against different architectures and selectively target them for installation in the mellanox SONiC image.
- How to verify it
Build SONiC for mellanox and verify it compiles successfully.
Why I did it
Fix the missing debian package for reproducible build issue.
The gnupg2 should be added into the version file.
https://dev.azure.com/mssonic/build/_build/results?buildId=118139&view=logs&j=88ce9a53-729c-5fa9-7b6e-3d98f2488e3f&t=8d99be27-49d0-54d0-99b1-cfc0d47f0318
The following packages have unmet dependencies:
gnupg2 : Depends: gnupg (>= 2.2.27-2+deb11u2) but 2.2.27-2+deb11u1 is to be installed
E: Unable to correct problems, you have held broken packages.
The issue was caused by the gnupg2 removed, and not detected.
sonic-buildimage/build_debian.sh
Line 250 in 4fb6cf0
sudo LANG=C chroot $FILESYSTEM_ROOT apt-get -y remove software-properties-common gnupg2 python3-gi
Why I did it
Fix the openssh build issue, upgrade from 8.4p1-5 to 8.4p1-5+deb11u1.
https://dev.azure.com/mssonic/build/_build/results?buildId=120209&view=logs&j=88ce9a53-729c-5fa9-7b6e-3d98f2488e3f&t=8d99be27-49d0-54d0-99b1-cfc0d47f0318
+ sudo dpkg --root=./fsroot-broadcom -i target/debs/bullseye/openssh-server_8.4p1-5_amd64.deb
dpkg: warning: downgrading openssh-server from 1:8.4p1-5+deb11u1 to 1:8.4p1-5
(Reading database ... 44818 files and directories currently installed.)
Preparing to unpack .../openssh-server_8.4p1-5_amd64.deb ...
Unpacking openssh-server (1:8.4p1-5) over (1:8.4p1-5+deb11u1) ...
dpkg: dependency problems prevent configuration of openssh-server:
openssh-server depends on openssh-client (= 1:8.4p1-5); however:
Version of openssh-client on system is 1:8.4p1-5+deb11u1.
dpkg: error processing package openssh-server (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
openssh-server
+ clean_sys
How I did it
Upgrade openssh from 8.4p1-5 to 8.4p1-5+deb11u1.
How to verify it
Why I did it
When any of the test job failed in the test stage, the rerun will not work, the test stage will be skipped automaticall, so we do not have chance to rerun the test stage again, and the checks of the test will be always in failed status, block the PR to merge forever.
It should be caused by the condition in the Test stage, we should specify the status of the BuildVS stage.
How I did it
Fix stage dependency logic.
- Why I did it
During platform API SFP object initialization, there are two steps, one is to read the xSFP type from EEPROM, and another is to parse the xSFP DOM support capability. There is the possibility that the xSFP EEPROM is not ready when it started to read, which will result in the SFP object does not have type and DOM capability correctly initialized, which will cause further issues. So need to add a mechanism to retry in this case.
- How I did it
Add flags to indicate whether the SFP object has been correctly initialized or not, set the flag when an error happened and after all relevant bytes from EEPROM are correctly read out and parsed, clear the flag.
Leverage the Python decorator to decorate the related functions, each time when the related function is called the decorator will check whether the SFP object has been correctly initialized or not, if not it will read the EEPROM and parse again.
- How to verify it
Run SFP-related platform tests to make sure no new issue is introduced.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
The following packages have unmet dependencies:
libssl-dev : Depends: libssl1.1 (= 1.1.1n-0+deb11u3) but 1.1.1n-0+deb11u2 is to be installed
E: Unable to correct problems, you have held broken packages.
Fix sonic-db-cli high CPU usage on SONiC startup issue: https://github.com/Azure/sonic-buildimage/issues/10218
ETA of this issue will be 2022/05/31
Re-write sonic-cli with c++ in sonic-swss-common: https://github.com/Azure/sonic-swss-common/pull/607
Modify swss-common rules and slave.mk to install c++ version sonic-db-cli.
Pass all E2E test scenario.
<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [ ] 202012
- [ ] 202106
- [ ] 202111
Build and install c++ version sonic-db-cli from swss-common.
<!--
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/wiki/Configuration.
-->
update sonic-utilities submodule
8ac2810 [202111] [generate dump] Move the Core/Log collection to the End of process Execution and removed default timeout (#2225)
77891de [202111] Fix UT failed cause by change pycommon to use swsscommon (#2085) (#2231)
Advance sonic-submodule to get the following fixes:
ebdc242 Fix fbdorch to properly handle syncd FDB FLUSH Notif
8fd44da [ci] Don't publish gcov artifact when test failed
dcf6429 [ci] Change artifact reference pipeline to common lib pipeline.
387ed60 [ci] Use correct branch when downloading artifact.
169f597 [ci] Improve azp trigger settings to automaticlly support new release branch
- Why I did it
Update SAI pointer to include the following fix:
Fix size descriptor pool for rx/tx
- How I did it
Update SAI pointer to point on the new commit
- How to verify it
Run regression tests
#### Why I did it
There might be a case where service checker periodic operation determined that specific container is running but when it tries to perform an operation on it, it was already closed by the user. This is a valid flow and we should not log an error message, informative warning is enough.
#### How I did it
I reduce log severity.
#### How to verify it
I verified it manually.
- Why I did it
When LLDP is disabled through feature command, it gets spawned after reboot.
- How I did it
In syncd.sh check if the service is enabled before spawning automatically during cold reboot.
- How to verify it
Disable lldp feature. Perform cold reboot and verify its not spawned.
sonic-swss
25fe915 [crmorch] Prevent exceededLogCounter from resetting when low and high values are equal (#2327)
1c3c5e0 [BFD]Retry create BFD with different source UDP port on failure (#2225)
d5775b1 Skip consistent fail tests (#2269)
sonicutilities
5800b73 Fix header for the output table following 'show ipv6 interface' command (#2219)
- Why I did it
Recent change to delay PMON service in case of fast/warm reboot introduce an issue when restarting only SWSS service after fast/warm reboot for Nvidia platform.
Since the timer is triggered only when the system boot, in a scenario when the system is after a fast/warm reboot and the user restart SWSS service, as part of syncd.sh script, PMON service will stop but the timer will not start again.
- How I did it
On syncd.sh script, in case of fast/warm indication, check if pmon.timer is running.
If it is running it means we are at the first boot and continue normally.
If it is not running, meaning the service was restarted, start the timer to keep the system behavior consistent.
- How to verify it
Run fast/warm reboot.
service swss restart.
Observe PMON service starting.
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
- Why I did it
Update SAI version to 1.21.2.1 in order to gain the following fixes:
1. Optimize descriptors apply time
2. BFD - notify SONiC for admin-down event
3. Don't disable used tunnel underlay interfaces
- How I did it
Update SAI pointer and update SAI version on make file
- How to verify it
Run regression tests
sonic-utilities
e2dd672 [yang] remove mistakenly added parameter for 'get_module_name' (#2193)
2b12a39 Add check to not allow deleting PO if its member of vlan. (#2141)
sonic-platform-common
309d169 [ssd_generic] Fix innodisk health regex (#287)
