We do not have any testing inside DIB for testing disk-image-create
logic. Lets do some smoke testing for all our supported image formats.
Also adding a run_functests.sh so we can extend this later without editing
the jenkins job.
Change-Id: Ie491e27f00bde54f73af6b47c9696ec04d973b14
This change uses blkid to identify the fs type during redhat-common
extract-image. The image is mounted with -o nouuid for redhat/rhel
images that have XFS filesystems.
This is required when building images from the same base image
as the host VM to avoid "Filesystem has duplicate UUID" mount
failures.
Change-Id: I066289fbb27733a5a555242a0e2c363d58dd27d0
Closes-Bug: 1443706
Now that we have a generic yum-minimal element, just use it in centos
instead of rinse. Adding base as an element-provides of yum-minimal
because this element conflicts with the base element.
Co-Authored-By: Gregory Haynes <greg@greghaynes.net>
Change-Id: I15275d821781171c118f21aa0c0bca55f65a65b3
The loopback handling in the Linux kernel limits the filenames of
files associated to loopback devices, see also linux/loop.h.
This is reflected also on userspace, as kpartx will silently do nothing
(exiting with 0) when requesting to remove a filename longer than 64
characters, as that name will obviously not match the truncated
filename. The result of this is that, when extracting qcow2 images for
the first time, if the qcow2 filename is long enough then the loopback
device will not be removed, remaining as stale in the host.
As a workaround, use a temporary file name when convering a qcow2 image
to raw, instead of using the base name of the qcow2 file.
While this still will not fix the issue when manually using a long
temporary directory (e.g. TMP_DIR=/very/long/etc...), at least should
avoid it in other cases.
Change-Id: Ibf46cd313a9d89412c0e1068fa0993be6c5a29db
Our logic to determine needed image size doesnt fully account for the
in-filesystem journal. This only shows up when creating images that are
very small relative to the FS journal size.
Change-Id: Ic3c2bcd31ec4fee6bcd9f67767842eb3fbe20d3a
This commit changes Ironic deploy ramdisk to find out
the virtual media device by using labels instead of
looking at the model of block device. This helps in
finding out the device irrespective of the hardware.
Corresponding Ironic change is
If5b78d9af7048f2631d050ee5ce01ab7a67e2354.
Closes-Bug: #1429340
Change-Id: I5e8a706989bad13051eb47db0b1e762e6c672318
The build host might not necessarily have a complete set of dirs
required in its PATH. It will likely be better to statically code a
complete(ish) set of PATH entries inside the function.
Some distros (ex: archlinux) are lacking some dirs commonly found in a
PATH. If this is used as a host OS, it will transfer this incomplete
PATH into the chroot, where other guests (ubuntu, centos) will fail to
find basic binaries due to the lack of a /bin entry.
Change-Id: I084aff7e449f5de811a6169ec90e352ada7da439
Commit b4a1f1c190 wrongly changed the format of the available
images. There was a missconfiguration on the buildservice which produces
the images so no static links were available. That's fixed now so use
the correct names again.
Change-Id: Iac4cbc8672da67f5a89ac2f1be8bb9530215ea19
The centos-minimal approach of using rinse does not, it turns out, work
on centos. That's a bummer. It's also rather heavyweight. Instead, with
minor machinations, we can just use yum itself pointed at a chroot.
Also adding fedora-minimal element which creates a fedora image using
the new yum-minimal approach.
Co-Authored-By: Gregory Haynes <greg@greghaynes.net>
Change-Id: I026fd9d323e786dae5bb67824c6501067e1ceaa3
If you don't want cloud-init, you may need to get a few things
from config-drive because you may be operating on a cloud with no DHCP.
In that case, simply reading some values from config-drive and writing
out either DHCP or static network info, in addition to grabbing ssh keys
is helpful. Both Infra and bifrost want this for their images.
Co-Authored-By: Gregory Haynes <greg@greghaynes.net>
Change-Id: I2746ed256b9783eab058b803130d3ccac484eaeb
We support building elements without depending on the base element.
Breaking install-types out into its own element while making base depend
on it so elements can depend in it without base.
Change-Id: I104543d5482c76f60902e9fc32d91e196eeab51a
Turns out that updating packages last causes some pretty
non-intuitive behaviour if you are trying to pin a package
to a specific version. Lets just update the base RPMs first...
subsequent installations should install the most updated version
anyways (unless they are pinned).
Also moves the package-installs script from the 00 step to 01 so
we can do the update first.
Co-Authored-By: Ben Nemec <bnemec@redhat.com>
Change-Id: I962046cc6048e852e6582fbc579f88bb73e23fdd
This fix prevents loading of unsigned ubuntu kernel in UEFI secure
boot environment when image is created using 'iso' element.
'iso' element uses 'linux' and 'initrd' modules of grub2 to load
kernel and initrd respectively. The grub2 implementation of Ubuntu
can load unsigned kernel when these modules are used.
Ubuntu has Grub2 modules 'linuxefi' and 'initrdefi' which exits
boot process if unsigned kernel is used in UEFI secure boot mode.
The 'iso' element should use these modules in grub.cfg to prevent
loading of unsigned kernel when node is booted in the UEFI secure
boot environment.
'linuxefi' and 'initrdefi' works seamlessly when node is booted in
normal UEFI boot mode (non-secure).
Fedora do not have this issue. This fix has been tested in Fedora
environment. It works fine.
Closes-Bug: 1443114
Change-Id: If256ba1f7d7c149482d0f37fabcdfa8ed22e3f91
ubuntu-signed element would install 'linux-signed-image-generic' that
provides signed kernel that can be used for deploy in UEFI secure boot mode.
Package 'linux-signed-image-generic' ships signed kernel with extension
'.efi.signed' (Ex. '/boot/vmlinuz-3.13.0-49-generic.efi.signed').
The kernel modules directory for signed kernel and unsigned kernel is same.
It is without 'efi.signed' extension to its name. This is different from normal
practice of directory naming in '/lib/modules' (Ex. For signed kernel
'vmlinuz-3.13.0-49-generic.efi.signed', modules directory is
'/lib/modules/3.13.0-49-generic').
This needed some changes in '/lib/ramdisk-functions' and 'ramdisk' element to
copy kernel modules.
The signed kernel package contains both signed and unsigned kernel. The
unsiged kernel is without extension '.efi.signed' (Ex.
'/boot/vmlinuz-3.13.0-49-generic'). This required change into
'/lib/img-functions' and 'baremetal' element to pick up signed kernel version
when this element is used.
Closes-Bug: 1443076
Change-Id: I60061cbea847b47fa752b9463cfd387e8e7f0635
The targetcli element was triggering a bunch of errors from dracut
when we installed all of Python. It turns out this is because there
were filenames with spaces in the find output and the loop didn't
handle that properly. This switches to a while loop that can
handle odd filenames.
Change-Id: Iacbf16f26f2bc9991840250dc8ae7990db54d811
Currently, calling the troubleshoot function in a ramdisk script
doesn't work as expected on dracut ramdisks. This adds an alternate
troubleshoot implementation that will behave as intended.
I did not make it conditional on a kernel param as was done in the
original because dracut can behave strangely if you allow it to
continue after an error. Always dropping to a shell immediately
should be less confusing.
Change-Id: I98000f4ac6d7890b1f44fe4d10394ac0ea332fcb
Do not rely on environment changes (like exporting REG_HALT_UNREGISTER)
to persist between different hooks run. This helps when the hooks are
run in different new environments every time.
Instead, in 99-unregister redo the same checks on REG_METHOD as done in
00-rhel-registration, still respecting REG_HALT_UNREGISTER in case the
user does not want to unregister the image generated.
Change-Id: Id594dcd72334f38a2fa96da21206da77a83d7a1a
Closes-Bug: #1434431
