Recent changes brought l2 vlan concept which does not have DHCP
clients behind them and so DHCP relay is not required. Also,
dhcpmon fails to launch on those vlans as their interfaces
lack IP addresses. This PR backposts #6527 that limits launch
of both DHCP relay and dhcpmon to L3 vlans only.
original-pr: #6527
singed-off-by: Tamer Ahmed tamer.ahmed@microsoft.com
When submitting a new official build for broadcom, vs, it prompts a error message, which says the job is not defined.
It was caused by the default option "[]", which is not empty, it is used as the jobGroups parameter.
Why I did it
Improve the version of the Pull Request build by changing the local branch name.
How I did it
Change the default branch name merge to [target_branch_name]-[pullrequestid].
How to verify it
For official build, the version is not changed.
For pull request build, the version as below:
Why I did it
Fix the boolean value case sensitive issue in Azure Pipelines
When passing parameters to a template, the "true" or "false" will have case sensitive issue, it should be a type casting issue.
To fix it, we change the true/false to yes/no, to escape the trap.
Support to override the job groups in the template, so PR build has chance to use different build parameters, only build simple targets. For example, for broadcom, we only build target/sonic-broadcom.bin, the other images, such as swi, debug bin, etc, will not be built.
Why I did it
Failed to build the centec-arm64 for no space in docker data root.
How I did it
Change to use the data root to the folder under /data.
See detail info about DOCKER_DATA_ROOT_FOR_MULTIARCH in the file Makefile.work.
How to verify it
Set the environment variable, then the /data used as docker root.
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>
