Mount all the usual /dev /sys /proc pseudo filesystems during the
root.d phase in order to make sure they are available for the rpm
post-installation phases.
Change-Id: I28221debf1036d9eb5137161757eb30811eafab1
On Centos and RHEL 6 the init system is upsart but but networking is using
sysv compatabiliy and a code path the handle this situation.
We can't use DISTRO_NAME because the centos-minimal element sets it to
centos for CentOS 7 but the centos element sets it to centos for CentOS 6.
Change-Id: Ib8e33ed78b3d6a5737eb7449bccef2d33f72b131
Closes-Bug: #1638527
The refresh operation must happen after the cache has been added in
order to ensure that whatever is in the cache is still relevant to
the current build and we are not using stale packages.
Change-Id: Iafd718e9738f85b8c235806c027665730f44d89b
AFAICT this is no longer necessary. I've tested minimal and image
builds and they seem to work.
The original problem seems to be with installing the package in the
chroot, although it was never quite clear it ever affected the Red Hat
path.
This code is currently broken (see
I884cb1e78ad8c31d985f3fc94a58091b993edd7d). This is proposed as an
alternative to I74eed074494134334d5e49042bb5214bd0dd7339.
Related-Bug: #1627000
Change-Id: Iafe3611f4eec3c6357587a6cae6a30a261686ead
Recommended packages are usually useful but we normally don't need
them in order to have a working system. As a result, avoid pulling
them in when doing a regular package installation or a distribution
update. Extra packages can be pulled in using the usual '-p' parameter
or from within the elements that actually need them. The results of
this change are quite significant, resulting to gains from a few dozen
of MBs up to a few hundred depending on the selected elements.
Change-Id: I5838829c631990c7a1f3b67548accd9a603fe20c
When debugging, this is very noisy for very little value. If we need
to specifically debug this script we can turn up the level.
Change-Id: Ie15f16397c37e718aa919853697cbf2c5c08503c
Because environment files are sourced into the current environment,
they shouldn't be setting global settings like tracing else they
affect every preceeding import. This is quite confusing when only
half your imports are traced in the logs, because it was either turned
on, or off, by a preceeding environment import.
There is a corresponding dib-run-parts change in
I29f7df1514aeb988222d1094e8269eddb485c2a0 that will greatly increase
debugability for environment files by deliberately logging what files
are sourced and consistently turning on tracing around their import.
This isn't strictly necessary (since dib-run-parts with the prior
change will just turn tracing off after import anyway) but it's a
decent cleanup for consistency. A bare-minimum dib-lint check is
added. Documentation is updated.
Change-Id: I10f68be0642835a04af7e5a2bc101502f61e5357
cloud-init-local needs to be run in the boot runlevel because it
modifies services in the default runlevel. When a runlevel is started
it is cached, so modifications that happen to the current runlevel while
you are in it are not acted upon.
Change-Id: Ifeae0071fc9e738ec223ec0df271559ad6e0196b
Add a new opensuse-minimal element to build small and highly
configurable openSUSE based images using the zypper-minimal element
as the main building mechanism
Change-Id: Iebfc4ad4aff763e511b093f1607b55851ccbddcb
All SUSE-based elements can benefit from the mkinitrd phase to move it
to a more generic location.
Change-Id: Ife171d462a393b6ac0bf2c5eaa48ea25eaf4d1cc
Since http://httpredir.debian.org is unreliable is selecting a mirror
to use, we'll now default to http://ftp.us.debian.org/debian. In
fact, in openstack-infra we have been overriding httpredir.debian.org
for a while, now make this default in diskimage-builder.
Change-Id: I48658bc076e13a0913821197e4120c73618fef8f
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Move the opensuse utilities to the zypper element so they can be used by
SUSE or zypper based elements. This brings the zypper element somewhat
in line with the rest of the package manager elements.
Change-Id: I8aa2849231454216cdd47629a5e2d6e45769dbbe
Depending on the pool id used, so many repos are brought,
including not valid ones that cause image to crash, or repos
that include conflicting packages.
Before enabling repos, disable all previous ones, so we
can be sure that we only bring the repos specified in the
parameters.
Change-Id: Ifd4d8d1d4fa954cd2593669e516e3201f2d6f6c1
Move managing of SSH host keys into a dedicated element.
Because glean doesn't generate SSH host keys anymore, we need to do it
with a systemd script. This is already handled by CentOS / Fedora so
we don't want to add it there.
This was done to address the upstream bug in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500192
Change-Id: I31ad667672e08350872db21a83445fe0aa7a4a39
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Grub is first removed and then installed during RHEL image building. The
grub2 package typically requires the same version of grub2-tools, so if
we just remove and install the grub2 package, the installation can
potentially fail on being out of sync with grub2-tools version. Removing
and reinstalling both packages fixes this issue. Those packages are
already in package map for RHEL as "grub-pc", so we can use this alias.
Change-Id: Iefd9c17fffd43de3fea260510ad218b1322eecb3
Closes-Bug: #1627000
We are currently wasting about 10 minutes per deploy waiting for
DHCP on interfaces that will never get it. By default, the timeout
seems to be 5 minutes (the 10 minutes is because we boot both the
IPA ramdisk and the deployed image, and each waits for 5 minutes),
which is excessively long to get a DHCP response. This change
shortens the time to 30 seconds. If an interface hasn't gotten a
response in 30 seconds, chances are it's not going to. A 30
second wait should reduce our wasted time to 1 minute, which is
more reasonable.
This is being done in the systemd unit file because the -timeout
option to dhclient doesn't seem to override what is configured in
dhclient.conf, and doing it in the systemd file means that this
change will be limited to only the interfaces configured by
dhcp-all-interfaces.
Change-Id: Ia8610e3def39c937eb0c861fdc9bc571ec39f9f4
Closes-Bug: 1626673
Because we are using the building platform's "yum" to do the initial
install into the chroot, it is affected by the base-system's
/etc/yum.conf.
pip-and-virtaulenv in I82acb865378a0fa5903a6267bfcee0e2962eced0 added
"exclude=python-pip..." in /etc/yum.conf to stop the package manager
overwriting the installed pip. Now our CI images have built with
this, we are now picking up this exclude on centos. Since on F24
dnf->python->python-pip we end up failing to build the the chroot
because python-pip can not be satisifed. In a general sense, however,
this could be caused by any configuration put into /etc/yum.conf that
is incompatible with installing into the chroot.
yum has the option to disable all excludes which is used here. This
seems to be the best way to isolate the chroot install from any
excludes that may have been done on the base system for various
reasons. I did consider using a completely separate yum.conf we ship
with dib ... but let's start simple.
This should fix the current gate failures on centos
Change-Id: I4e4cc8ed09a29c4057ade34ea93025139e191bf5
