Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade ifupdown2, and clean up some code #8418

Merged
merged 6 commits into from
Aug 13, 2021

Conversation

saiarcot895
Copy link
Contributor

@saiarcot895 saiarcot895 commented Aug 11, 2021

Why I did it

These changes are in preparation for upgrading the base OS to Bullseye.

How I did it

How to verify it

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106

Description for the changelog

  1. Upgrade ifupdown2 from 1.2.8 to 3.0.0 (the latest version). Add a patch to fix handling broadcast addresses.
  2. Remove --net=host from the RUN_OPT of other docker containers. This is now handled by files/build_templates/docker_image_ctl.j2. Specifying this twice in a docker run command will be considered an error starting from Docker 20.10.
  3. For tacplus, fix a code issue that gets detected with GCC 10 related to strncpy not guaranteeing that the destination buffer will have a null byte.
  4. Update the Bullseye slave image with some changes needed there.
  5. For deb package builds that are done directly from slave.mk, do a clean after building it, to remove generated and compiled files. This will be needed for Bullseye, as some components will be built once for Buster and once for Bullseye, and having existing generated files will mess up the builds (at least for autoconf-based packages).

A picture of a cute animal (not mandatory but encouraged)

strncpy calls need to be mindful about the destination buffer size
passed in and doing an explicit null termination.

Signed-off-by: Saikrishna Arcot <[email protected]>
With a Bullseye base image, and PTF being based on Stretch, if there are
autogenerated files that are reused from the Bullseye build for Stretch,
then autoconf-based packages will fail. This is because the default set
of CFLAGS that dpkg passes in includes `-ffile-prefix-map=`, which is
not a supported flag with the GCC in Stretch. Then, when running `make
clean` in a Stretch environment, make will try to regenerate the
autoconf-based files with the cached set of CFLAGS from Bullseye. This
causes an error, since that flag is unknown.

To work around this, after each build, clean up all built objects and
autogenerated files. This makes sure that it is cleaned up in the same
environment as the build environment.

Note that this issue affects just autoconf packages. For apps using just
regular Makefiles, they will probably be fine (they'll still be cleaned
up as well).

Signed-off-by: Saikrishna Arcot <[email protected]>
The start template script that this value is used in will determine what
network namespace to use, and will add --net=host if it needs to run in
the host namespace.

With Docker 20.10, if --net=host is specified twice in docker run, then
it errors out. Therefore, remove the explicit --net=host in the run
options setting and let the start template script specify it.

Signed-off-by: Saikrishna Arcot <[email protected]>
lguohan
lguohan previously approved these changes Aug 11, 2021
In version 3.0.0, If a broadcast address is specified in
/etc/network/interfaces, then when ifup is run, it will fail with an
error saying `'str' object has no attribute 'packed'`. This appears to
be because it expects all attributes for an interface to be "packable"
into a compact binary representation. However, it doesn't actually
convert the broadcast address into an IPNetwork object (other addresses
are handled).

Therefore, convert the broadcast address it reads in from a str to an
IPNetwork object.

Also explicitly specify the scope of the loopback address in
/etc/network/interfaces as host scope. Otherwise, it will get added as
global scope by default. As part of this, use JSON to parse ip's output
instead of text, for robustness.

Signed-off-by: Saikrishna Arcot <[email protected]>
When using dpkg with the --root flag to install a deb package in a
chroot, dpkg checks to see if the users and groups specified in the
/var/lib/dpkg/statoverride file are valid. The problem is, it checks
against the host system's /etc/passwd and /etc/group files, instead of
/etc/passwd and /etc/group inside the chroot.

In the slave image for Buster, cron appears to have been automatically
installed, and so the crontab group existed. This doesn't appear to be
true for Bullseye, so explicitly install it. This makes sure that the
crontab group exists on the slave image itself.

Also install the mock python 3 package, this is needed by some test.

Signed-off-by: Saikrishna Arcot <[email protected]>
@saiarcot895 saiarcot895 force-pushed the sw-upgrade-and-fixes branch from 1ef5d24 to dda1a8f Compare August 12, 2021 18:25
@lguohan lguohan merged commit 91f9b6f into sonic-net:master Aug 13, 2021
@saiarcot895 saiarcot895 deleted the sw-upgrade-and-fixes branch November 3, 2021 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants