Instead of hard-coding a list of binaries to include in the dracut
ramdisk, use the existing binary-deps.d functionality to provide a
list. This will allow other ramdisks (such as discovery) to add
the binaries they need.
Change-Id: Ib7ffa15e08db1cc45e93a8f2a5c01369772c93ff
Busybox should be installed and managed from the ramdisk element,
since that is common to all elements that need busybox. In
addition, we do not want busybox installed when building Dracut
ramdisks, so it can't be in the deploy-* elements.
Change-Id: I2656d20b466138f7f6dfcf558ba90c6909151d3c
This commit adds a new element named 'iso' to build a bootable
ISO image for the kernel/ramdisk emitted by the 'baremetal' or
'ramdisk' element.
Change-Id: I89d175a29e2d0bc64b47fe527f0d0f6875f6849a
During internal testing we are getting the following error from
merge-svc-map-files
File "/tmp/image.K2MYCphY/hooks/extra-data.d/10-merge-svc-map-files", line 54, in main
with open(data_path, 'r') as dataFile:
IOError: [Errno 21] Is a directory: '...diskimage-builder/elements/svc-map'
Somehow IMAGE_ELEMENT contains a extra white space that manifests itself
as an element without a name. It is very hard to find where this is coming from so
instead this patch makes merge-svc-map-files more robost to this situation
Change-Id: Id1500ead8a77d691408617dcdc4e095bc5775be8
The element builds dracut from source on Ubuntu because the
Ubuntu dracut package is broken and very old, so it can't be
installed properly and causes a number of other issues that
are fixed by using a newer version of Dracut.
This initial version should work in virtualized environments.
Further validation of its suitability for real baremetal
deployments will need to be done in the future, but this should
be sufficient to enable that work.
Regarding Dracut specifically, in order to limit the changes
needed in the existing scripts this element continues to use a
cut down version of the /init script that we were building for the
existing ramdisk. However, instead of running it as pid 0 it is
run as a Dracut pre-mount hook. This allows Dracut to set up all
of the hardware and system bits, while falling early enough in the
Dracut sequence to complete the deployment before Dracut would try
to boot off the hard disk.
bp tripleo-juno-dracut-ramdisks
Change-Id: I144c8993fe040169f440bd4f7a428fdbe3d745cf
This reverts commit 4bf38a829a.
This variable is pointless since we can always replace it with
/lib/systemd.
Commit I459f7514ab35082d31607968252a9005fa25de2a will fix the issue
in tripleo-image-elements.
Change-Id: I524badb6836a0d04a5f6e6a5b5d95920fd923ef6
Until now there was a possibility for two elements to install hooks
with the same name, so one of them was overwritten. Change logic to
copy the hooks and fail in case one with the same name exists.
Change-Id: Ic2c46835b27c9319f7a889ffd0ccf3f5ccc1f0cd
Closes-Bug: 1251952
We are autodetecting and configuring devices in dhcp-all-interfaces
so having one configured in /etc/network/interfaces by default
is redundant and slows boot down.
Change-Id: Ic4e8a0668c793d21ed2dd96908649c9a77264f67
Closes-Bug: #1239480
After being deprecated two releases ago, finally remove any reference
for the support of first-boot.d
Change-Id: I08d67404ef48cad61db3b18fb86e970abfa5d2b6
There are some situations (use of libpam-tmpdir) where the $TMPDIR is
defined per user, so any sudo call will define an specific $TMPDIR for
the root user which doesn't exist inside the chroot.
Change-Id: I866651fed520007506c7be83837d3791ed9f2235
Closes-Bug: #1330290
In our official image builds we are only allowed to use resources
that are "blessed" by the build system. This means that external
things like git repos and tar files are not allowed. Currently,
even in offline mode source-repositories expects those things to
be available in the cache, so we need a way to disable it entirely.
This change adds an environment variable NO_SOURCE_REPOSITORIES
that does so. It can be set in an environment.d script so elements
that might rely on a source repository will know it's not available.
The 02-lsb script in redhat-common is one such example and is
updated to handle this case.
Change-Id: I0de63bee6ad79733d6711478c707a9b41593e85f
This is the final released image; it is the same one deployed in many
cloud provers such as HP and AWS. It is also safe from all known
vulnerabilities up to its release
Change-Id: Ib8ba561662d2a98da55eb292b850dc019226dd59
Each distro had its own copy of the file, but they were all the
same and it's actually installed in redhat-common so it belongs
there.
Change-Id: Iad15f39fd28d1c4e20d30dcb2eb0ae6f2fa2b015
When uploading images to multiple clouds it is possible that the same
image will be needed in multiple formats to accomodate hypervisors
across clouds. Update disk-image-create's -t flag to take a list of
desired output image formats so that a single disk-image-create can
output all of the desired image formats.
Change-Id: If121b2342ae888855ba435aa3189f039e985b812
qemu-img convert can take a few minutes to complete, or far longer
on heavily loaded systems. Notify the user that the image is
undergoing conversion to save them just seeing END PROFILING.
Change-Id: I1ad61ce5ed011b721d48e2d12fb42ef4aa5cd1f6
If we entered the cleanup trap due to exit with an error code we should
exit dib with an error code.
Change-Id: Iee1a05668b3239113fb91a2da0d9a66d7de4db6b
The centos7 images come with the base version of cloud-init already
installed.
---
$ virt-inspector CentOS-7-x86_64-GenericCloud-GA-7.0.1406_01.qcow2
...
<application>
<name>cloud-init</name>
<version>0.7.5</version>
<release>10.el7.centos.1</release>
<arch>x86_64</arch>
</application>
...
---
I think this is a hang-over from early rhel7 images that didn't have
it.
Change-Id: Idf488942222d9e6bca4d66f04f5af42e6707944d
instack runs this script on a system where epel has already been
installed, which causes the yum command to fail. Only installing
the epel-release rpm when it isn't already present addresses the
issue.
Change-Id: Ia179d7c7ed69ea5f785b5dcd16394c7663a145cc
A user reported symptoms where the losetup line used to detach the
loopback device was failing in tar mode. We don't need to detach a
device that does not exist.
Change-Id: I807996e16199288927b49b4f300ae9b461cb8fe7
Closes-Bug: #1378033
rpm-distro element was trying to install bin programs into the
image but it doesn't provide any. Move that logic into the yum
element which provides the install-packages bin.
Change-Id: Id5339fc7ffbef6327fe41f50a3e39ab30b6d0320
disk-image-create processes a DIB_IMAGE_CACHE variable and exports it,
but there are several elements that ignore the value and wrote out
the base location themselves. Use the variable everywhere so that it
will get overridden everywhere.
Change-Id: I00fff354d6c931ad67cf3052d055f0e4604dfdc8
The way redhat-common's extract-image script was creating the base
tarball caused file capabilities to get dropped, which meant that
things like ping in RHEL 7 images was unusable for regular users.
This change adds the necessary options to the tar call to maintain
as many extended attributes as possible.
--acls and --selinux are intentionally omitted, and the selinux
xattrs are filtered out because all of those items cause issues
in our chroot environment. We restore selinux attributes at the
end of the build anyway so that shouldn't be a problem.
bz reference: https://bugzilla.redhat.com/show_bug.cgi?id=1144149
Change-Id: Ibff99ce9bde01bc5ecf95dc3a5d3e2cebe5015b9
EPEL 7 was released September 30. The beta release rpm was removed
from the repo and was replaced with the final release rpm.
Change-Id: I103a2f7abd7563869b9e39ccc1fbb3cfbd9ff6ae
In both of the changed files in this patch, the $DISTRO_NAME usage
is checking against "centos". The valid value for the centos7
element for $DISTRO_NAME is "centos7"[1].
[1] http://git.io/8IvuTw
Change-Id: I0c4a4b2ecf87c7a9283d10071f6feb494a6c716a
A sanity check that cache-url does the right thing when presented
with the appropriate curl return codes. This change brings in the
test code for scripts from tripleo-image-elements, which needs to
be factored out into a place both projects can use it.
I'm stubbing out curl so we don't have a dep on curl in our unit
tests, and because I've seen some strange behavior out of curl in
the gate that caused random failures in this test.
Change-Id: I31e6b06b45415feec7285511d07e65eb78d0d045
