As described in the comment and associated bugzilla, the behaviour of
setfiles has changed in Fedora 26 to require "-m" situations where
labeled file-systems are mounted below non-labeled file-systems. Our
loopback/chroot system appears to trigger this nicely, leading to a
setfiles call that does nothing without this.
Change-Id: I276c6f6a4fb44f4bea5004f6b4214f94757728ae
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
As described in the referenced bug, the dependency solver in yum
doesn't handle weak dependencies well and in some cases, such as
Fedora 26, can end up choosing coreutils-single (the busybox-esque
single binary) instead of actual coreutils, which then causes problems
with conflicting packages later.
Change-Id: I2907bf3b74c146986b483d52cc6ac437036330b4
On a system where the packaged pip/virtualenv is up-to-date with
upstream (such as Fedora 26 ... for now), we don't reinstall, which
then violates a bunch of assumptions later on. Force install.
Change-Id: I6ebcda0351997fa7e32f0e6e77a98b2c33764e3f
It turns out dnf argparse can't handle negative numbers without "=".
It's actually documented in the man page
--latest-limit <number> ... If <number> is negative skip <number>
of latest packages. If a negative number is used use syntax
--latest-limit=<number>
But who reads that :) This started failing with Fedora 26
Change-Id: I884af94c07fa11b010f69863047a04711b14f21e
We expect LC_ALL for non-C locales to be working inside
images, so always install glibc-locale for openSUSE.
Change-Id: I8fe92773e377539070d9d9fe2960a6202bb80a18
The code in mkfs correctly extends the command line with a '-n' for
vfat but does not currently do it for fat. This means that mkfs for
fat ends up with a '-L' which is what you'd do for everything like
ext[234].
The change just treats fat like vfat in the one place where this check
is required.
Change-Id: If65dfd949acdadff33a564640fb42ea73026a786
Closes-Bug: #1703063
The purpose of the openSUSE element is to build openSUSE distribution
based images, so an additional community repo shouldn't be pulled into
the image. In addition the dkms dependency is blacklisted for SUSE
in the dkms element anyway, so this should be a noop.
Change-Id: I0aa06d9f4f110546032f910e3361840693d02de7
On Power systems console should be added the kernel command line
in the following order: 'console=tty0 console=hvc0'.
The first one is the graphical console. The last one is the serial
console. The kernel enables all the consoles pointed through the
kernel command line. However, only the last one will receive
input/output during kernel boot. All the other consoles will be
enabled after the boot.
Change-Id: I0069f608e0ab104d3778954e033fb82ed5ea7693
We replace the base resolv.conf with an "outside" copy so that
resolving works when we're in the chroot.
Installing resolvconf package modifies the in-chroot resolv.conf to a
symlink (to /var/run) which it wants maintained in the final image.
We have the existing "immutable" check for a created resolv.conf file,
but no eqivalent for a symlink.
This adds a check to see if the resolv.conf is a symlink and leave it
alone if it is, assuming it has been re-created in the chroot.
I have tested this with ubuntu-minimal+resolvconf with
dhcp-all-interfaces and the system seems to work with resolvconf
working correctly.
Change-Id: Idd5a26e9d55979bd951577d5b098ed4bfba91ad3
The python3 package actually contains some core modules (like the xml
one) which are not present in the python3-base on which is pulled by
the python3-devel package. As such, it's best to have it installed
similar to python-xml for python2.
Change-Id: I5cd5d1127ae62d6753c2ace44965179c5400bb9a
In order to support {CentOS,RHEL}7 for building cloud images we need to
handle the differences in grub packaging from Ubuntu. We also need to
populate the defualt location for cloud images for CentOS builds.
Change-Id: Ie0d82ff21a42b08c4cb94b7a5635f80bfabf684e
gnupg2 does not exist on openSUSE and there is no need to explicitly
install it. Fixes the following problem in the OpenStack CI
2017-06-28 09:28:29.071275 | + sudo PATH=/usr/sbin:/sbin:/home/jenkins/bin:/usr/local/bin:/usr/bin:/bin:/usr/games zypper --non-interactive install gnupg2 squashfs
2017-06-28 09:28:29.124994 | Loading repository data...
2017-06-28 09:28:29.287514 | Reading installed packages...
2017-06-28 09:28:29.713161 | 'gnupg2' not found in package names. Trying capabilities.
2017-06-28 09:28:29.713234 | No provider of 'gnupg2' found.
Change-Id: Ie90c3cf6d478ae4e178df0ce61072e9ee15b2259
When a download redirector redirects to a broken mirror, timeout
quickly rather than waiting until the overall job is being timed out.
Change-Id: If7eb63d406aaf61f71aa9203cf708c474aa63fd0
The 'packages' variable already contains the packages we need so
use it instead of duplicating the packages.
Change-Id: Id22e1862f9654e66252d03a0fed9839cf004d750
This was just to avoid our initial gate crisis, and has been put into
project-config with I45b4b181369032155f8908ee11641d2327586e6f
Change-Id: I3ab57b4455b39ccc3fa94ef1be2193fa7f082fb6
Several people have popped up in IRC recently with failures in these
elements. Without Python 2.7 available in the image they are
unsupported (OpenStack hasn't supported it for a long time). Remove
these to avoid further confusion.
The centos/centos7 DISTRO split that has happened with centos-minimal
is unfortunate but I don't think it helps to rename centos7/rhel7 ATM.
To summarise; DISTRO=centos7 means image based build,
DISTRO=centos && DIB_RELEASE=7 means the minimal build.
In the future, I think it is important that the minimal builds and
image builds set the same DISTRO. This reflects that "upper" layers
shouldn't care about the exact building of the lower layers. I see
CentOS 8 going one of two ways
1) the changes are so significant, we start separate centos8 /
centos8-minimal elements. They both set DISTRO=centos8 (and
DIB_RELEASE to point-release maybe?). This means we have to update
all "if DISTRO == centos || DISTRO == centos7" branches to also check
for "centos8". Evenually (!) "centos" goes away for versioned DISTRO
only
2) we restore centos element with DISTRO=centos and DIB_RELEASE=8, and
centos-minimal remains the same. This means we have to audit all "if
DISTRO == centos" calls to make sure they're appropriate for version 8
(stick a "&& DIB_RELEASE=7" on them all basically).
I'm not sure we can fully decide until we start to see excatly how the
distro switching/matching bits look, but (2) is consistent with Ubuntu
and probably the preferred solution.
Some "rhel" parts have been cleaned up. More could be done in
rhel-common, but given our lack of coverage of that I'd prefer to
leave it for now.
Change-Id: I6ea784116ef59ca22878c8512c963f29c815a00a
When running dib-lint vi temp files .*.sw? files are included which leads to
false positives. ALso all editor files are checked when looking at indents,
again this results in false positives.
Exclude those files by checking if they're in the user/project's
.gitignore setup.
Change-Id: I0a48174f22a8dad9e8f15bf3f70835d021a2d46f
The image download tests have long been too unreliable for the gate.
We need to cache the base images similar to how devstack caches it's
testing images. Let's move them to non-voting jobs for the time
being.
This means that the gate jobs are now all based on "-minimal" and are
using infra mirrors. Unfortunately, there is still some unreliability
because we currently have issues with infra mirrors being very slow
after AFS updates, leading to job timeouts. But we're on the right
path...
Also, I noticed we don't have tests of the "ubuntu" image-download
based tests, which were tacitly being tested by apt-sources before we
moved that to -minimal. Add simple tests for these.
Change-Id: Ie33ee49656872467ef68d753210032156bb6b2cb
In a system where python2 is not installed and /usr/bin/python is not
linked then the cleanup process will fail trying to invoke the python
script. Use the previously determined DIB_PYTHON_EXEC if it's available.
Change-Id: I128292808ccef92cc1803988b35caae5aa6fa541
This was previously defined as python2-devel (which is what rhel uses),
but the actual package name is python-devel. See:
https://software.opensuse.org/package/python-devel
Change-Id: Id61e5b05772d10c32b33d3e70cb64d5ebdcba6e4
I'm uncertain as to why this is using the "fedora" element for testing
... but it requires downloading the fedora .qcow on every test which
has shown to be unreliable. An easy thing to do is to switch it to
fedora-minimal; that will only involve downloads from local mirrors in
the gate.
Add redhat-rpm-config for minimal. I admit I have not fully gone
through why this is not pulled in. It's been an issue since
I459f2203fa145049dda185da952813118193d573 and there's all sorts of
bugs.
Change-Id: I37458e3926dae32a259bd5aa9efc645561b029a0
