As described inline, deprecate the "source" install for CentOS 8.
Overwriting the packaged tools has long been a pain-point in our
images, and the best outcome is just not to play the game [1].
However, the landscape remains complicated. For example, RHEL/CentOS
8 introduces the separate "platform-python" binary, which seems like
the right tool to install platform tools like "glean" (simple-init)
with. However, platform-python doesn't have virtualenv (only the
inbuilt venv).
So that every element doesn't have to hard-code in workarounds for
these various layouts, create two new variables DIB_PYTHON_PIP and
DIB_PYTHON_VIRTUALENV to just "do the right thing". If you need is
"install a pip package" or "create a virtualenv" this should work on
all the platforms we support. If you know more specifically what you
want (e.g. must be a python3 virtualenv) then nothing stops elements
calling that directly (e.g. python3 -m virtualenv create); these are
just helper wrappers for base elements that need to be broadly
compatible.
[1] http://lists.openstack.org/pipermail/openstack-infra/2019-September/006483.html
Change-Id: Ia267a60eecfa8f4071dd477d86daebe07e9a7e38
Don't install the "yum" package, which is a backwards compat around
dnf. With 687003f we should not need the backwards compat links any
more.
Add libcurl to avoid conficts with in the curl "-minimal" packages
that happens on CentOS 8. But skip it on Fedora, because it seems to
create more problems there (not going to pretend it isn't all a
hack ... but it seems to work).
Change-Id: I1de2703eb5075a0a22837b6898bd8eb960d080dd
A few places we either assume centos uses "yum" directly, or have
switching based on the distro type.
In both cases, we can use ${YUM} directly to avoid ambiguity
Change-Id: I71095a9bd1862f8956b5982fbbb3e1d213926c14
The libselinux packages etc don't exist for Python 2 on Centos 8 [1].
Ensure the package map installs the python3 versions.
We could probably invert the logic now, and make it so Centos 7 is the
"special" version that overrides things to install python2. Left
alone for now to avoid changing too much at once.
[1] https://bugs.centos.org/view.php?id=16458
Change-Id: I944cf4f2902c28728aa5bb9e2a00b3eef122d52e
CentOS 8 has the "new" split-up locales packages. Fedora 24 is now
long gone, so take out the old branch and apply the lang package
install to Centos 8 as well.
The manual locale cleanup is not necessary on Centos 8; skip it.
Change-Id: Ib65fc15fe471348793fd6efb034517f11abd905e
The repo format has slightly changed for CentOS 8 (s/os/baseos/).
Make the chroot builder look for a more specific repos.d directory
first named for the distro variable, then fall back to to top-level
dir (this avoids having to constantly change fedora).
Update the gate mirror setup and roles for new Centos 8 paths too.
Change-Id: I5b7f0c3624cac1d7aa7ed8bf6286b85d808b9c9a
This is no longer a valid option for dnf, and it puts out a lot of
warnings constantly about the invalid entry [1]. Remove it.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1653831
Change-Id: Iba0585cab3e5e78e9324196f276b2341e7bb9e3c
Install the Python 3 libselinux packages for Fedora platforms. I
think this is the right choice; Fedora is a Python-3 only distro so we
shouldn't default to installing the python2 libraries.
This has a practical effect if you're using Ansible with
ansible_python_interpreter=/usr/bin/python3 as it needs these
packages.
There is some small chance of breakage if you're using Ansible still
with Python 2, I guess. In infra I notice we bring this in with
"zuul-worker" project-config element. On balance, I think that if you
need the Python 2 packages for some reason, it should be a special
install and not part of redhat-common.
Change-Id: Ibcec0b3660d01b861838c2ae87ca43d98953ce32
This reverts commit 74317a3445.
What I missed was that "dib-lint" is distributed and people use this
to lint their out-of-tree elements (e.g. project-config). Because
dib-lint runs flake8 that really makes it a valid runtime dependency.
However, I don't think we need to pin to these particular versions of
flake8 in requirements (which I think was causing the original issues,
as it's fairly specific and easily conflicts). It seems to make more
sense to use the current uncapped "hacking" versions; so move them
from test-requirements.txt. Add a note so we don't forget again.
Change-Id: Ic2eee8f5b64c7020e98e0b1ef43a40f24411891a
We only need doc requirements for the doc jobs, so only install them
there.
Also, update docs job to not publish dirtrees.
Change-Id: I928f4e24970a680bf340ce15a08a4e72432fb0e4
Similar to https://review.opendev.org/#/c/663693/, the x64 packages
should be used for x86 architectures.
Change-Id: I5e8a4d58e96d65eb60fc539b8a1d56853b12faac
Closes-Bug: 1843820
linux-firmware and linux-firmware-whence (meta package for mostly iwl
firmwares) packages account for approx. 289 M install size on a F30
system, and linux-firmware for approx. 176 M on CentOS 7. Users needing
these firmwares are eventually baremetal users and are not looking for a
very minimal operating system base install like virtual image users are.
Thus, a non-minimal OS element is better suited for them. Alternatively,
it could be later considered a dedicated firmware element.
This is inline with I8ce65e1d357d15e8ed8995ad1dcaea02bbd1986f.
Change-Id: If104fc3c1e9349b8d501a2351fff1ab4c0dbc6a4
Flake8 was wrongly listed as a runtime dependency. That mistake messed
system flake8 version. Flake8 is a test requirement not a runtime one.
Also flake8 version is already determined by hacking version, so we
update it to recent version.
Change-Id: Iccd9dc6f2508127f17712d16dfce6538ff83807e
This is consistent with the previous simplication of
build targets in the opendev environment to refer to
"opensuse15" being the alias of "latest stable openSUSE Leap 15.x".
Change-Id: I904a3ca0d6dbddd2bb1a673836ab6a0ad249526d
Add a new environment variable $DIB_GZIP_BIN allowing builders to
specify a different gzip (such as pigz) to be used when compressing
tgz images.
Change-Id: Ifb617568140a149e2fda241e07ff8a59429e6697
We have an application breaking because /usr/share/cracklib is being
deleted from the image. The application installs its dependencies,
including cracklib, but since yum shows that cracklib is already
installed, it does not reinstall it.
Change-Id: Id6fccf76c706dbc6c2124abcfd12c1f10cef5e09
Newer openSUSE distributions install an absolute link to /run/netconfig
as /etc/resolv.conf in $TARGET_ROOT. as that points outside
TARGET_ROOT, we unintentionally wipe the system resolv.conf here
and break our ability to finish building the image.
Change-Id: I9d5aaa9fad2f81dcabfe19e2f1e6b6e50af597d7
This is a follow-on to I475a253091cbaf63687b91c748c31a6753bb0f57 as we
are still seeing issues on some clouds with unconfigured networking.
We increase the timeout, but also make it configurable so we can
fiddle it without a dib release in the gate.
To follow-on from the experimentation done by clarkb, I can confirm by
emperical testing on a Centos 7 image (from today, today being this
change's date) that setting
net.ipv6.conf.all.autoconf=0
by itself is "fatal" and the interfaces do not come up; i.e. nm does
not by default seem to re-enable ipv6 for the interface. However,
explicitly adding:
IPV6INIT=yes
IPV6_AUTOCONF=yes
to the interface file *does* seem to make it work, even if
"all.autoconf=0" is set (then again, there's also bugs about the
effect of this [1]). However, no extant distribution (I can currently
find) does anything like this by default.
If this continues, this may be an option. Another might be to avoid
the use of the nm-settings-ifcfg-rh profiles and move directly to nm
ini files with glean.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=11655
Change-Id: I869ebffc8cde3bbff573f6583fd9dd02a5598590
Upstream is now publishing 17.1 profile systemd stages
Also updates the docs that were forgotten in the last patch
Change-Id: I0f2e7976845b1d3c55ffe8869eec0bc04a191252
As described inline, we need to ensure the underlying directories in
the image are correctly labeled, or we get all manner of services
failing during boot with selinux in enforcing mode. Although the
problem is generic, this first shows up in Fedora 30 as systemd has
become more strict about namespace failures (I think) [1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1663040#c22
Change-Id: I52c1cc719884879169b606b00651aa26f5b783f1
This patch adds option DIB_YUM_MINIMAL_EXTRA_REPOS to yum-minimal to
allow DIB users to include extra repositories to their final image.
Change-Id: I89549f4b0f4c9470143b5064817acab5043e31c5
Something (possibly [1], but that change is at best cryptic) has
changed such that we don't get correct /etc/os-release files
installed. This flows on to grub half-installing itself, enough to
not fail the build but not enough to make something bootable.
Installing the -cloud release package gets it back, and seems like a
sane choice for dib.
[1] 617b1bed34
Change-Id: Iff0413887fad798273b2bfcb140cc07f36d54a04
As noted in the change, 7fd52ba841
increased the size of the EFI partition considerably. This has meant
that our padding upwards of the disk size is insufficient and EFI
builds (arm64 in particular) is failing due to out-of-disk errors
during final image operations like installing kernels.
Similar to the discussion we had in
I65fa13a088eecdfe61636678578577ea2cfb3c0c, this feels a bit ugly
because we're mixing logic here with sizes specified in block-device
config files. But it boils down to the same problem; we are
calculating the disk size here and passing it to the block-layer, so
unless we want to make large changes to the status quo about where
these sizes are calculated, small adjustments here are the most KISS
solution.
Thus we check if we have selected the EFI bootloader element, and thus
assume there will be a large system EFI partition and expand the disk
size accordingly.
Change-Id: Ifa05366c2f2b95259f3312e4dde8c85347075ba1
This debug statement lists every element found and its dependencies on
every build; it's just noise unless you're debugging the element
dependency solver itself. Remove from output.
Change-Id: I9281b953d958a3fd5e20edbc560a341a2fcc3deb
This seems to miss the exit code of the dracut process, which actualy
caused some issues in I8511669e188717494daf2bc1384a6dd346f942a4 where
it would have been much clearer to stop after the initramfs generation
failed.
Add some debug messages, and catch any errors from the final call.
Change-Id: I6f89441ec4709f5199535e15a7cc53a3a8af273d
Should install "grub2-efi-aa64 grub2-efi-aa64-modules" instead of
"grub2-efi grub2-efi-modules" for arm64
Change-Id: Iee3191b0944b3b862890d166a9d36bd592fe8f7e
Closes-bug: #1839816
