ARM Architecture support in SONIC
make configure platform=[ASIC_VENDOR_ARCH] PLATFORM_ARCH=[ARM_ARCH]
SONIC_ARCH: default amd64
armhf - arm32bit
arm64 - arm64bit
Signed-off-by: Antony Rheneus <arheneus@marvell.com>
Without quote, the command will ignore the version and
regard the ">" as a file redirection symbol and redirect
all the output to a file named the version range.
Signed-off-by: Shu0T1an ChenG <shuche@microsoft.com>
Define slave_base_tag_ref variable in Makefile.work containing
specific base image tag to use, rather than always defaulting
to :latest.
Add an ARG command before FROM statement in Dockerfile.user
for sonic-slave and sonic-slave-stretch. ARG variable defaults
to latest if slave_base_tag_ref not specified in Makefile.work.
The presumption to always refer to the :latest tagged Docker base
image when creating the user image causes problems in a shared
build server environment, where the most recently created base
image (i.e. the current :latest tag) may not be compatible with
the current build. For example, different users working in
different branches may all be sharing the same build server.
Signed-off-by: Greg Paussa greg.paussa@broadcom.com
- What I did
Added a DOCKER_AVOID_BASE_TAG_LATEST build option to rules/config that forces the Docker user image creation to refer to its base image by a specific tag rather than rely on the :latest tag. This is needed in a shared build server environment where builds from different developers and/or different SONiC branches all converge on the same Docker daemon instance running on the build server. The :latest tag is always assigned to the most recent base image built, which might not correspond to the base image needed for a particular build, thus causing various build errors that mostly manifest as missing Debian packages or package version mismatches.
NOTE TO REVIEWERS: This PR relies on Docker support of "ARG before FROM," which was first introduced in Docker version 17.05.1-ce. Although there is no mention of a minimum required Docker version for the build server in the SONiC Building Guide pages, please consider whether it is reasonable to assume that Docker 17.05.1-ce or later must be used for SONiC build hosts before approving this PR.
- How I did it
Added an ARG before the FROM statement at the top of the sonic-slave/Dockerfile.user and sonic-slave-stretch/Dockerfile.user files. The ARG variable defaults to latest, but can be overridden in Makefile.work to reference the SLAVE_BASE_TAG so that it refers to the specific, matching base image for the build. This override is activated by un-commenting the DOCKER_AVOID_BASE_TAG_LATEST = y line in rules/config.
* Update frr to frr-7.0.1
* Fix a typo
* Set right permissions on /etc/frr
* Convert external file links from debian to Azure
* Revert python3 fix
* Build frr using more than 1 job
* Add SWIG as dependency for libswss-common
* [dockers]: Upgrade SNMP docker to stretch build
* Removed patch-> 0003-CHANGES-BUG-2743-snmpd-crashes-when-receiving-a-GetN.patch
* update platform-common submodule
* adding PyYAML package to stretch dockerfile
* Installing redis package via pip in stretch dockerfile
* again updating platform-common submodule
* revert back the snmpd version to 5.7.3+dfsg-1.5
* upgrading the snmpd version to 5.7.3+dfsg-1.7+deb9u1 with openssl backport support
* update sonic-snmpagent submodule
* purge libdpkg-perl package in Dockerfile
* revert back the snmpd version to 5.7.3+dfsg-1.5
* minor change in series file
* Upgrade database and telemetry docker to stretch build
Signed-off-by: Jipan Yang <jipan.yang@alibaba-inc.com>
* Remove SONIC_STRETCH_DEBS list add for redis and telemetry
Signed-off-by: Jipan Yang <jipan.yang@alibaba-inc.com>
* [docker-radvd]: upgrade docker radvd to stretch based
* install jinja>=2.10
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* install pip packages for testing sonic-utilities
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* set storage driver to vfs
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* [build]: put stretch debian packages under target/debs/stretch/
* in stretch build phase, all debian packages built in that stage are placed under target/debs/stretch directory.
* for python-based debian packages, since they are really the same for jessie and stretch, they are placed under target/python-debs directory.
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* [baseimage]: install picocom 3.1 in base image
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* add picocom to stretch build
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* fix slave.mk bug
Signed-off-by: Guohan Lu <gulv@microsoft.com>
