To ensure dracut does not load nouveau we need to explicitly disable it via
omit_drivers.
This change adds a method to drop in arbitary dracut conf files to an element
which are picked up by dracut-regenerate and included in the chroot where we
run dracut.
The disable-nouveau element just adds a conf file with
`omit_drivers += " nouveau"`
The default dracut conf files in /usr/lib include a similar file to omit the
nvidia kernel modules.
Change-Id: I6375e4843fd08d1410141fbbd8658042dcd5ad05
Closes-bug: 1842664
Per the linked bugs, this does not seem to have a quick resolution.
The bug mentions that the copr nightly repos have other known issues,
so there just does not seem to be a good solution until fixed packages
are imported upstream. For now, pause Fedora jobs to get the gate
working.
Change-Id: Ib349592c3fcf2008fcab9ae8875de1c997eef7d5
Seeing this at the end of the tripleo overcloud full build:
99-selinux-fixfiles-restore: line 69: [: too many arguments
Change-Id: I8fb10f3d3d38723b41190ae1898757e6df073945
The vhdutil utility is completely dead; the whole subsystem it relies
on was removed with [1] so it's not even vaguely possible to keep it
up-to-date.
I took the .raw images on a nb and used the qemu-img there (so Xenial)
and generated some VPC images; uploaded them to rackspace and the all
seemed to boot fine. If there was a problem, maybe it's been fixed on
either the qemu or RAX side in the previous few years.
Thus swith to qemu-img to generate the vhd images too.
[1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5c883cf036cf5ab8b1b79390549e2475f7a568dd
Change-Id: I3099d2ebb958370fcec623087a093b2c8dbdc6c4
Add option to set the suite subpath after the release name for the
security mirror URL independently in the debian-minimal element,
since this can differ between mirrors.
Change-Id: I4cc8f54fba012986423e30e19bff276208b8ad62
With the introduction of centos 8 we have constructs like
if [[ $DISTRO =~ (centos|fedora) && $DIB_RELEASE -ge 8 ]]
This is intended to match the "centos7" element (from the =~) but it
was missed that this is setting the DIB_RELEASE to "GenericCloud".
I think it makes more sense for this to be a numeric release, and
makes constructs like above work. There really isn't any other type
of image to choose here; thus we move it into a new, centos7
specific variable.
Note that when the centos 8 images are available, we want to move to a
generic "centos" element that will handle both 7 and 8 together (same
as rhel) based on DIB_RELEASE and deprecate centos7; this works with
that environment too.
Change-Id: I2e6b7848070d6452c0563e2a122447627c6e6bf7
We are debugging a upstream dnf segfault that is consistently making
this job fail. Make it non-voting for now while this is sorted out.
Change-Id: I538e9d1b380e78549229b71e47a776ab97dd1b9c
It turns out that this breaks ipv6 config with NM. Instead what we want
is for glean to not up interfaces on boot (see the depends-on).
Change-Id: I6c5bc76c433e29f02d3266ab8f669015125ec954
Depends-On: https://review.opendev.org/#/c/688031
This adds CentOS 8 into functional and boot tests.
This completes centos-minimal support, documentation is updated and a
release note is added.
Change-Id: I435c2967b4f49faeb6d6edf189907b9f96e80357
As described inline, NetworkManager and dhcp-client make up the basic
networking for centos 8 installs; bring them into the base image.
Although in infra we then use simple-init, some other users find this
helpful.
Change-Id: Ib9f32e73bf9109cc1b659fe1deceb1a15301ffeb
By default network-scripts package isn't installed, so the directories
for these files don't exist either. Skip by default for Centos 8.
Change-Id: I194ec3735e17f27e586386541dc51f775b01e510
Use the wrapper calls from Ia267a60eecfa8f4071dd477d86daebe07e9a7e38
to install glean.
Using this wrapper means we cover all cases without more and more
branches; it should work for python2, python3 and also the special
case of RHEL/CentOS where dib-python points to the special
/usr/libexec/platform-python (which is python3.6 with inbuilt pip)
Change-Id: If624e8bb66ce0761fc0d5f34c2bed8b93a7daeee
NetworkManager with simple-init has proven to be stable in OpenStack
infra, switch to it by default for CentOS and Fedora. For CentOS 8
and Fedora, add a check to make it the only option. Thus only CenOS 7
remains optionally using the legacy scripts; this is likely not used
anywhere (infra is really the primary user, where NetworkManager is
already used); we can likely remove this variable (and hence path) in
a future cleanup.
In the setup, remove rhel7 element which was never really tested.
Reorganise the fallthrough to call out the default paths as doing
nothing.
Change-Id: Ic996956da4b85f7d95179b8df9881d5f52c091af
Currently, the serial console is hardcoded to ttyS0 in the bootloader
element. This is a challenge for users that want to build images for
some baremetal servers. Supermicro servers, for example, use ttyS1 for
the serial over lan interface.
This patch adds a new environment variable DIB_BOOTLOADER_SERIAL_CONSOLE
that can be set to override the default.
Change-Id: Ie8173be8690ac0b7164ce9e5b66d3c1c18f844d6
Add option to set the security mirror URL independently in the
debian-minimal element, since this can not be overriden by the
standard DIB_DISTRIBUTION_MIRROR variable.
Change-Id: I145844a410d06a479e68db1bf6d5d0159389305c
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
Two bugs are addressed.
1) The sysprep element was broken in that it only truncates
/etc/machine-id, but not /var/lib/dbus/machine-id. systemd will
not generate a new machine-id if /var/lib/dbus/machine-id is
present[1], it will simply copy it to /etc/machine-id.
We observed machine-ids being packaged in /var/lib/dbus/machine-id
on several distros: Ubuntu Bionic, Fedora 29, Debian Stretch.
CentOS 7 and Ubuntu Xenial do not contain packaged machine-id as
far as I can tell.
All test builds were performed using -minimal elements.
2) A second bug existed where debian-minimal did not run the sysprep
element at all, so a stretch image I tested contained a populated
/etc/machine-id AND a populated /var/lib/dbus/machine-id.
[1] https://www.freedesktop.org/software/systemd/man/machine-id.html#Initialization
Change-Id: Ibb28b6e90d966a845de38a2cd5a1e8babd2604bc
Gentoo is at 17.1 now, most code was updated in [0], update the test job
accordingly.
[0] I0f2e7976845b1d3c55ffe8869eec0bc04a191252
Change-Id: I30e018e67f3637ce36b3ef6e20380453fe6b2bb9
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
