Why I did it
Fix the wrong build options and improve display name for some tasks
1. Fix the wrong build architecture for arm64 and armhf
2. Fix the build timeout parameter
Why I did it
To monitor the SSD health condition in DellEMC S6100 platform post upgrade.
A daemon is introduced to monitor the SSD every one hour.
To check for SSD status at boot time and at the time of cold-reboot.
All these changes are supported only for newer SSD firmware.
Porting changes from 201911 branch
Added a platform_reboot_pre_check script to prevent cold-reboot based on SSD status.
Depends on Azure/sonic-utilities#1557
#### Why I did it
- xcvrd crash was seen in latest 201811 images.
- For Dell S6100,API 2.0 uses poll mode while 1.0 was still using interrupt mode.
#### How I did it
- Modified get_transceiver_change_event in 1.0 to poll mode in all the related branches.
Why I did it
sonic snmp subagent build was failing recently.
How I did it
install python-arptable and psutil in sonic slave docker to address sonic snmp subagent build issue.
How to verify it
build 201811 image locally.
Signed-off-by: Ying Xie ying.xie@microsoft.com
Why I did it
for 201811 build image, swsssdk wheel package is not getting build due to redis==2.10.6 requirement issue. Notied that after upgrading pip to 20.3.3, we are experiencling this issue.
the issue
21:10:41 /sonic/src/sonic-py-swsssdk /sonic
21:10:41 running test
21:10:41 Searching for redis==2.10.6
21:10:41 Reading https://pypi.python.org/simple/redis/
21:10:41 Couldn't find index page for 'redis' (maybe misspelled?)
21:10:41 Scanning index of all packages (this may take a while)
21:10:41 Reading https://pypi.python.org/simple/
21:10:41 No local packages or download links found for redis==2.10.6
21:10:41 error: Could not find suitable distribution for Requirement.parse('redis==2.10.6')
21:10:41 [ FAIL LOG END ] [ target/python-wheels/swsssdk-2.0.1-py3-none-any.whl ]
21:10:41 slave.mk:422: recipe for target 'target/python-wheels/swsssdk-2.0.1-py3-none-any.whl' failed
21:10:41 make: *** [target/python-wheels/swsssdk-2.0.1-py3-none-any.whl] Error 1
21:10:43 Makefile.work:132: recipe for target 'target/sonic-aboot-broadcom.swi' failed
21:10:43 make[1]: *** [target/sonic-aboot-broadcom.swi] Error 2
21:10:43 make[1]: Leaving directory '/data/johnar/workspace/broadcom/buildimage-brcm-201811'
21:10:43 Makefile:6: recipe for target 'target/sonic-aboot-broadcom.swi' failed
So, what I have understood till now, if pip v20.3.3 is able to produce a wheel that is not installable because it raises pip._vendor.packaging.version.InvalidVersion or some error like that (resource- > pypa/pip#9206), it just raises an exception when building the wheel.
SO, this issue occurs when we pinned down pip to 20.3.3 in short.
As of now, there are two solutions mentioned below.
pin down pip to 20.3.3(which it is) and explicitly install packages.
pin down pip to 20.3.4(pip wheel now verifies the built wheel contains valid metadata, and can be installed by a subsequent pip install.)(resource-> https://pip.pypa.io/en/stable/news/) -- didn't try yet
How I did it
Install nose explicitly for mockredispy
Install redis==2.10.6 for swsssdk tests.
How to verify it
Run local build after removing all previously built dockers.
* [build] Fix the snmp docker build error. (#7452)
Issue is get_pip.py is moved to pip 21.1 (https://github.com/pypa/get-pip/commits/main) which is not compatible with 3.6.
Issue of pip itself is fixed as part of 21.1.1 in pip community (pypa/pip#9835).
However get-pip.py is still not updated to latest pip. Also get.pip.py does not support python 3.6 version explicitly (pypa/get-pip#88)
Step 15/29 : RUN curl https://bootstrap.pypa.io/get-pip.py | python3.6
---> Running in bece31f49267
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 1891k 100 1891k 0 0 9564k 0 --:--:-- --:--:-- --:--:-- 9600k
Traceback (most recent call last):
File "<stdin>", line 24298, in <module>
File "<stdin>", line 139, in main
File "<stdin>", line 115, in bootstrap
File "<stdin>", line 96, in monkeypatch_for_cert
File "/tmp/tmp5fnxrz0a/pip.zip/pip/_internal/commands/__init__.py", line 9, in <module>
File "/tmp/tmp5fnxrz0a/pip.zip/pip/_internal/cli/base_command.py", line 12, in <module>
File "/tmp/tmp5fnxrz0a/pip.zip/pip/_internal/cli/cmdoptions.py", line 30, in <module>
File "/tmp/tmp5fnxrz0a/pip.zip/pip/_internal/utils/hashes.py", line 2, in <module>
ImportError: cannot import name 'NoReturn'
The command '/bin/sh -c curl https://bootstrap.pypa.io/get-pip.py | python3.6' returned a non-zero code: 1
How I did:
Got the file from https://github.com/pypa/get-pip/tree/21.0 and added to the buildimage
pin pip to the previous release 21.0.1. (Similar is done in other public repos eg: grpc/grpc-java#8115)
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Why I did it
201811 build was failing due to the newly added bcm config file key word was not on the permitted list
How I did it
add phy_an_lt_msft to permitted list.
How to verify it
Build device package.
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
Why I did it
To enable autonegotiation/link training on some Broadcom-based platforms (Arista 7060 and 7260, Celestica DX010)
How I did it
Add appropriate SOC property for enabling the feature to the Broadcom config files of appropriate platforms
Also convert line endings to UNIX format for one Celestica file
see below error:
+ sudo https_proxy= LANG=C chroot ./fsroot easy_install pip==20.3.3
Searching for pip==20.3.3
Reading https://pypi.python.org/simple/pip/
Couldn't find index page for 'pip' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
No local packages or working download links found for pip==20.3.3
error: Could not find suitable distribution for Requirement.parse('pip==20.3.3')
How I fix:
Install python-pip via apt-get
Pin the version to 20.3.3
Master has same changes.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Basically mlnx-fw-upgrade.sh is used in two places:
1. https://github.com/Azure/sonic-buildimage/blob/201811/files/scripts/syncd.sh#L109
```bash
/usr/bin/mst start
/usr/bin/mlnx-fw-upgrade.sh
/etc/init.d/sxdkernel start
/sbin/modprobe i2c-dev
```
2. https://github.com/Azure/sonic-buildimage/blob/201811/device/mellanox/x86_64-mlnx_msn2700-r0/platform_reboot#L32
```bash
ParseArguments "$@"
${FW_UPGRADE_SCRIPT} --upgrade --verbose
EXIT_CODE="$?"
```
In first case the `stdout` is redirected to `syslog` directly by `systemd`.
Thus, the `syslog` logger is only required in second case.
#### Why I did it
* To improve ASIC/CPLD FW upgrade logging
* To improve CPLD upgrade time
#### How I did it
* Added `syslog` logger support
* Replaced `_pciconf0` -> `_pci_cr0` to reduce CPLD upgrade time
#### How to verify it
1. mlnx-fw-upgrade.sh --upgrade
Backport of https://github.com/Azure/sonic-buildimage/pull/7031 to the 201811 branch
#### Why I did it
To enable parsing the `AutoNegotiation` element from the LinkMetadata section of minigraph file
#### How I did it
Parse the value `AutoNegotiation` element from the `LinkMetadata` section of minigraph file. If the element is present, an `autoneg` key will be added to the port in the `PORT` table of Config DB with a value of either `0` or `1`
If an `autoneg` value is present in port_config.ini, the value from the minigraph will take precedence, overriding that value.
Also remove `AutoNegotiation` and `EnableAutoNegotiation` elements from the `DeviceInfo` section, as we will use this data in the `LinkMetadata` section to determine whether to enable auto-negotiation for a port.
Why I did it
The S6000 devices, the cold reboot is abrupt and it is likely to cause issues which will cause the device to land into EFI shell. Hence the platform reboot will happen after graceful unmount of all the filesystems as in S6100.
How I did it
Moved the platform_reboot to platform_reboot_override and hooked it to the systemd shutdown services as in S6100.
Fixed the "/host unmount failed" issue as well in 201811.
How to verify it
Issue "reboot" command to verify if the reboot is happening gracefully.
#### Why I did it
- The iSMT SMBUS I2c bus number conflicts in different kernel versions.
#### How I did it
- Add I2cbus number detector for iSMT bus
- Replace iSMT bus number in fancontrol config
[CRM] Safety check for division by 0 (#1569)
[crm]: Typecast to unit64_t to avoid divide by 0 during overflow (#1550)
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
Updated commit hash pointer in the relevant Makefile for the repository which contains SDK packages.
Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
With the release of pip21.0 (https://pypi.org/project/pip/#history) on branch
201811 stretch build is failing with below error logs:
As per https://pypi.org/project/pip/ pip21.0 does not not support python2
from Jan 2021. To fix this tag the pip to 20.3.3 version which was being used last
and is working fine.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
fixesAzure/sonic-utilities#1389
With the recent changes in sudoer files. The show commands fails for the read-only users.
The problem here is the 'docker ps' is failing in the function [get_routing_stack()](8a1109ed30/show/main.py (L54)) therefore all the CLI commands are failing.
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
Fix#119
when parallel build is enable, multiple dpkg-buildpackage
instances are running at the same time. /var/lib/dpkg is shared
by all instances and the /var/lib/dpkg/updates could be corrupted
and cause the build failure.
the fix is to use overlay fs to mount separate /var/lib/dpkg
for each dpkg-buildpackage instance so that they are not affecting
each other.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
when parallel build is enabled, both docker-fpm-frr and docker-syncd-brcm
is built at the same time, docker-fpm-frr requires swss which requires to
install libsaivs-dev. docker-syncd-brcm requires syncd package which requires
to install libsaibcm-dev.
since libsaivs-dev and libsaibcm-dev install the sai header in the same
location, these two packages cannot be installed at the same time. Therefore,
we need to serialize the build between these two packages. Simply uninstall
the conflict package is not enough to solve this issue. The correct solution
is to have one package wait for another package to be uninstalled.
For example, if syncd is built first, then it will install libsaibcm-dev.
Meanwhile, if the swss build job starts and tries to install libsaivs-dev,
it will first try to query if libsaibcm-dev is installed or not. if it is
installed, then it will wait until libsaibcm-dev is uninstalled. After syncd
job is finished, it will uninstall libsaibcm-dev and swss build job will be
unblocked.
To solve this issue, _UNINSTALLS is introduced to uninstall a package that
is no longer needed and to allow blocked job to continue.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
sonic-slave tag only allows all lower case. In case the user
name is mixed case, we need to change user name to all lower case.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
87e1a36 2020-04-16 | Do not set PG to Buffer porfile mapping again if already exist. (#1261) (HEAD -> 201811, origin/201811) [abdosi]
Signed-off-by: Guohan Lu <lguohan@gmail.com>
backport c4b5b002c3
make swss build depends only on libsairedis instead of syncd. This allows to build swss without depending
on vendor sai library.
Currently, libsairedis build also buils syncd which requires vendor SAI lib. This makes difficult to build
swss docker in buster while still keeping syncd docker in stretch, as swss requires libsairedis which also
build syncd and requires vendor to provide SAI for buster. As swss docker does not really contain syncd
binary, so it is not necessary to build syncd for swss docker.
[submodule]: update sonic-sairedis
* 9a66890 2020-06-28 | [build]: add option to build without syncd (HEAD -> 201811, origin/201811) [Guohan Lu]
Signed-off-by: Guohan Lu <lguohan@gmail.com>
Why I did it
During upgrade, if config is loaded from minigraph, it would miss TACACS credentials. This leads to device losing remote user accessibility
- How I did it
During update graph, when config is loaded from minigraph, look for TACACS credentials back-up and load that if available
- How to verify it
Remove /etc/sonic/config-db.json, save TACACS credentials in /etc/sonic/tacacs.json and do a Image upgrade. Do image upgrade and boot into new image. Verify remote user access is available.
NOTE: This change is available in master via PR #6285
Haliburton needed watchdog daemon to monitor the basic health of a machine. If something goes wrong, such as a crashing program overloading the CPU, or no more free memory on the system, watchdog can safely reboot the machine,
* [SAI] Add PFC pause duration counters in microseconds
**- Why I did it**
To add PFC pause duration counters in microseconds
**- How I did it**
Updated SAI to version 1.14.3
**- How to verify it**
**- Description for the changelog**
[Mellanox] Update SAI to version 1.14.3
This PR adds the changes in #6198 to 201811 branch to support warm-reboot image upgrade for kvm images.
The sai.profile file in kvm images overrides the warmboot file with path /var/cache/sai_warmboot.bin. Since the directory /var/cache is not mounted in syncd, it will be cleared in an image upgrade, the warm-reboot image upgrade will fail if the file is put in the directory.
Remove the path that overrides the default path. The warmboot file path will then be the default value /var/warmboot/sai-warmboot.bin. Since /var/warmboot/ is mounted by /host/warmboot/ in the host, it could survive an image upgrade.
Since DOCKER_SYNCD_VS is no longer being used, the mount option does not properly mount the warmboot file directory. Fix the mount option so that the directory is properly mounted.
