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
Centos6 is no longer reasonable to expect to function with openstack,
and infra does not host a mirror for it.
Change-Id: I95ccf5840807fee73d6e78d596c82709e476bb3a
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
It was noticed on a very busy system this can take about 1s per loop.
This starts to add up on thousands of processes.
Firstly, prune out all the kernel threads. Then introduce a very
small inline python script to find any pids that seem to be in the
chroot without forking to examine each one. After that the existing
loop just kills anything as before.
Change-Id: Icc7bc7eda80ffcd636f97e6542d70c220e9c225e
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
Most of our distros support DIB_DISTRIBUTION_MIRROR for setting the
mirror to be used when building. This has a major downside where if
someone would like to create a static configuration for building various
distro images it cannot set DIB_DISTRIBUTION_MIRROR (think of the case
where we want to run our tests).
By adding support for DIB_$DISTRO_DISTRIBUTION_MIRROR this problem is
resolved.
Change-Id: I92964b17ec3e47cf97e3a3091f054b2a205ac768
mkfs's arguments are
mkfs [options] [-t type] [fs-options] device [size]
So it seems our MKFS_OPTS are really supposed to be fs-options, rather
than options to mkfs itself.
Why didn't we notice? It's quite a trap -- mkfs.ext2 has a "-t"
option, so when we're calling
$ mkfs -i 4096 ... -t ext4 ...
We actually just fall-back to the default from the mkfs wrapper which
is mkfs.ext2 which works! But when you make that, say, xfs, we're not
calling the right wrapper at all.
Also update documentation
Closes-Bug: #1648287
Change-Id: I3ea5807088ab361bd9c235c07fb1553fbaf9178b
This commit updates the CLI utility name hpssacli to
ssacli as part of company name change from HP to HPE.
ssacli will work seamlessly for all the cases where
hpssacli is used.
It also updates the custom URL location for ssacli
utility with new location.
Change-Id: I2de4d3430e7308d25e36dc6960783699aa17dfae
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
We do not have the concept of "not installed" in v2, so remove the
obsolete code looking for a now non-existent variable.
Also, log the version at startup. This can help when
debugging from logs
Change-Id: I964c4cf207c10666afc5bc7ab9f2bfb9b1897c1e
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
Do md5 and sha256 in parallel to speed things up for larger images.
Change-Id: Ib782fe54e4286ba2749a7ab7247f5d41a887a370
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Because we're still fundamentally a python program calling a
shell-script, there's some oddities like not having the virtualenv
bin/ in the $PATH if we call disk-image-create directly.
We can detect this, however, and activate the virtualenv before we
fork the disk-image-create shell script so everything "just works".
See also nodepool change I0537cbf167bb18edf26f84ac269cbd9c8a1ea6a2
Change-Id: Ibfea6cf6a6fd0c7f1e468d501c61ae0b58992042
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
