dracut has a "hostonly" mode where it builds an initramfs that is
suitable for booting the system it is building on. This is on by
default, but obviously in our nested multi-platform chroot situation
this is fraught with danger.
As highlighted by [1] our builds were inadvertently turning off
"hostonly" mode when the mountpoints in the chroot were not found.
The CentOS 7.3 behaviour change broke this and we ended up with an
initramfs with no file-system modules.
Iaf2a1e8470f642bfaaaad3f9b7f26cfc8cc445c9 introduced a regeneration of
the initramfs, which I think does work as described because it runs in
the loopback device.
However, dracut includes a package that installs configuration
overrides to build a generic initramfs. This is really what we want,
and should solve the problem no matter where the initramfs is created.
Add this package into yum-minimal and remove the extra re-create call
which should not be necessary.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1405238
Change-Id: I5d203f2abe743cb23a44d449850e692a948e7871
openSUSE 13.1 was discontinued on Feb 3rd, 2016, so defaulting
to it doesn't make sense (see https://en.opensuse.org/Lifetime).
Leap 42.2 is the most current release that is supported by
disk-image-builder and being tested in a 3rd party ci.
Enable functests for it to ensure we're not regressing again.
Moved to non-voting gate first.
Depends-On: Iff495b3cd0b6c3558c44cf4883651eca67b572d6
Change-Id: Iae6cd34a5853f1e309861c554d94d8595cbd9993
For some reason [1] introduced -m option without ever checking that the
mapping exists. Because there is no grub-ieee1275 mapping anywhere (not
in base, not in bootloader), pkg-map fails. So stop using the mapping in
package-install of grub-ieee1275 on ppc.
There is another patch that tries to solve the same bug by adding the
mapping [2]. I think it is better to undo the breakage introduced in [1]
first, and then, if various distributions have differing names for the
package, introduce various mappings. My reasoning is that at the moment
this element is broken for all ppc64 distributions. This patch would
fix it for some (namely, Ubuntu). Then we can add mappings as tests
are done for other distributions.
[1] Ibca43173c30c2a74a73a2e2d9dd6d6d832c62694
[2] Id2b0f63a7015f883070fd59b79fd96a1c024858a
Change-Id: I8425876c26e9e416c8ce2f53a4e38d26b4208633
Closes-Bug: #1624021
dracut has a loop [1] where it probes top-level directories, tries to
find what block device they are on, then determines the file-system of
that block device. It then puts those file-system modules into the
initramfs for boot.
Since we install the kernel package during the chroot phase, / there
is not a block device and thus this loop matches nothing and we end up
with no file-system modules in the initramfs. This results in a very
annoying silent boot hang.
By moving re-generation of dracut into finalise.d phase, we run inside
the final image where / is the loop-device; the root file-system gets
detected correctly and the ext4 module is included correctly.
[1] http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.sh?h=RHEL-7#n1041
Change-Id: Iaf2a1e8470f642bfaaaad3f9b7f26cfc8cc445c9
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Tripleo-image-elements have an install.d file '05-heat-cfntools' that runs
the following command:
virtualenv --setuptools $VENV
With the recent change to diskimage-builder (moving the install of pip
and virtualenv to the 10- range) virtualenv is no longer available for
this elementr; as a side-effect, the trove kick-start command is now
broken and gate jobs are failing.
The solutions is to move the (now) 10-install-pip to 04-install-pip.
This should still alleviate the race condition that
https://review.openstack.org/#/c/408277/ attempted to fix, as all
*-package-installs files are 00-, 01- or 02-.
Change-Id: Ia4e01f00c4c5e9a2087df1e2a91d9154480a0422
Closes-Bug: #1650008
Commit 6278371eaa13("Make dib-python use the default python for distro")
added default python version for various distros but it missed openSUSE
which leads to build failures since the openSUSE elements are pulling
python2 packages. Add openSUSE to the list of python2 distributions
until python3 support for the openSUSE elements is in place.
Change-Id: I95f1fa849a22607c430387a2a915f9d19c9c209f
We are explicitly calling python in this element which does not work on
systems which only have python3.
Change-Id: Ia730850a48e2478fd5461710a9d2619408725cd8
Now that we are explicit about what python version we intend to use
for dib we can have package installs optionally install packages
depending on this. Add a new dib_python_version that matches on the
DIB_PYTHON_VERSION string set by dib-python.
Co-Authored-By: Adam Harwell <flux.adam@gmail.com>
Change-Id: I70659aab7d12924bdb9bc0489a7f02d5fd0dbb39
We currently have this as a 01- script which causes it to race with
package-installs (the deps are installed after the script runs).
Change-Id: I7b04b4c186eaae783b8e2bda1aa724c0d7823eab
systemd doesn't like it when service files have the executable bit
so this causes it to spam the journal with messages like:
Configuration file /usr/lib/systemd/system/dhcp-interface@.service is
marked executable. Please remove executable permission bits.
Proceeding anyway.
Removing the executable bit from the install permissions should
eliminate those messages.
Change-Id: Ie1bc39465b3fcb55dcda5cee9e46a128a6ccffcb
Right now dib-python works by trying to find any python on a system in
an order of precedence. A much better way is if we are explicit about
the python we intend to be there which will allow us to make better
decisions in other elements (such as allowing for package-installs to
take into account DIB_PYTHON_VERSION) as well as allow for users to
specify a preferred python version.
Co-Authored-By: Adam Harwell <flux.adam@gmail.com>
Change-Id: Ie609de51cc5fcde701296c9474e315981d9778a2
Adds conflict checking to the sysctl-write-value script
to detect settings from multiple elements conflicting.
Change-Id: If312d199388036d6f4103e94dca99249cb3bcbaf
Files in $element/environment.d are meant to be sourced, so drop
the executable bit. Moreover, drop the executable bit from a couple
of other scripts that are either meant to be sourced or simply because
they are configuration files.
Change-Id: I7f724dd9d409f4a835a136f12f48a84aa9acc41e
This element adds python-brick-cinderclient-ext to the make customized image
to support cinder local attach/detach functionality. Currently it has the
dependency on known bug<https://launchpad.net/bugs/1623549>, which would be
resolved with next release of python-brick-cinderclient-ext.
Change-Id: Idfe83bafa2843c781c18b83f1a3aece3ae852f78
Debootstrap only supports one apt repository to install packages from.
As a result, we do not consider the updates repo during debootstrap
causing us install a second kernel when we do an apt-get dist-upgrade
during build.
Lets use debootstrap to get us a minimal chroot, then add our repos and
install the correct packages from the start.
We also have to reorder the dpkg root.d scripts which configure apt so
they run before we perform our package installs.
Change-Id: I6a592db6f0a01d3b19d8e0786e63f1315a1ef647
Closes-Bug: #1637516
It's important to have the CA certificates on the target for ssl
crypto apps to work. Plus it's also important during bootstrapping
with diskimage-builder as tools like 'pip' etc need the certificates
in place in order to work properly. This fixes opensuse-minimal
image generation with the 'simple-init' element which was causing the
following error:
Download error on https://pypi.python.org/simple/: [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
Change-Id: Ie94cd3556f8ae523f60ce0155ba18ed752e6fbb6
It seems in the grub cleanup in
Iafe3611f4eec3c6357587a6cae6a30a261686ead I managed to unintentionally
drop systemd from the yum-minimal builds. By not pre-installing grub
we dropped some dependencies; the path is tortured ... grub2 ->
os-prober -> udev -> systemd-udev -> systemd (we don't even want
os-prober! So this whole thing was working by accident).
This manifests in *very* confusing ways.
Currently centos-minimal builds are failing late in the build with
services unable to enabled. dib-init-system was actually trying to
tell us that it didn't know what init was installed (because systemd
wasn't actually installed), but unfortunately it was not really
failing. This meant the service files were not copied correctly from
other elements, and thus fail to be enabled. I have corrected this
with I076c08190d40c315ad6a6d96a3823e9fc52630be which would at least
alert us earlier.
For Fedora 24, due to a bug in dracut dependencies [1], missing the
systemd-udev package fails the build of the initrd during the kernel
install. This then results in an initrd-less, unbootable system (see
also Ibaaa81124098f3c6febe48e455d3e1cd0a5f1761).
Add these dependencies explicitly.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1398505
Change-Id: I24ce648485c3d6f3c27ab8f87a638516b3727017
When you source a file that just does
export FOO=$(bar)
you miss any invalid return codes from "bar" (even under -e) because
bash returns the value of the "export", which is 0
On centos-minimal, we stopped bringing in systemd early and this was
causing dib-init-system to not know what init was available. Since it
did not fail correctly, it lead to confusing errors much later in the
build when service files were not copied correctly. See also
I24ce648485c3d6f3c27ab8f87a638516b3727017
A dib-lint check is added. One minor fixup is in 00-set-apt-sources
(this one is less likely to cause problems). I have run dib-lint over
project-config elements and none use this pattern.
Change-Id: I076c08190d40c315ad6a6d96a3823e9fc52630be
