Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
As motivation for this; we have had two breakouts of dib in recent
memory. One was a failure to unmount through symlinks in the core
code (I335316019ef948758392b03e91f9869102a472b9) and the other was
removing host keys on the build-system
(Ib01d71ff9415a0ae04d963f6e380aab9ac2260ce).
For the most part, dib runs unprivileged. Bits of the core code are
hopefully well tested (modulo bugs like the first one!). We give free
reign inside the chroot (although there is still some potential there
for adverse external affects via bind mounts). Where we could be a
bit safer (and could have prevented at least the second of these
breakouts) is with some better checking that the "sudo" calls
*outside* the chroot at least looked sane.
This adds a basic check that we're using chroot or image paths when
calling sudo in those parts of elements that run *outside* the chroot.
Various files are updated to accomodate this check; mostly by just
ignoring it for existing code (I have not audited these calls).
Nobody is pretending this type of checking makes dib magically safe,
or removes the issues with it needing to do things as root during the
build. But this can help find egregious errors like the key removal.
Change-Id: I161a5aea1d29dcdc7236f70d372c53246ec73749
Adds support for debian to iso.
Updated README to further clarify what the element does.
Change-Id: I17ac89cfbc84365860c591fab0e4c78123035983
Co-Authored-By: zhangjian <jian.zhang8@hpe.com>
This commit adds support for providing custom kernel
cmdline args while building deploy ISO. This is useful
for adding kernel cmdline like 'console=ttyS1' in
environment (assuming all bare metals have been configured
to output to COM2 in BIOS).
Closes-Bug: 1451634
Change-Id: I20b04d9d104cfe46df0439c3f567a721a27e186a
Starting from syslinux 5.00, isolinux.bin is dependent on
ldlinux.c32 to boot for BIOS machine. syslinux > 5.00 is
delivered with Fedora 21 cloud image which breaks the boot
from ISO if ldlinux.c32 doesn't exist.
Change-Id: If722f36aeaabc759d93ef6ae3f49b21bb840a92d
Closes-Bug: 1449882
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
This adds support to UEFI secure boot by copying signed shim and
grub bootloaders into ramdisk image.
Closes-Bug: 1419707
Change-Id: I1193cd3a9011855a6804966a31c7c0e28da90ada
There is a wide variety of tracing options through the various shell
scripts. Some use "set -eux", others explicity set xtrace and others
do nothing. There is a "-x" option to bin/disk-image-create but it
doesn't flow down to the many scripts it calls.
This adds a global integer variable set by disk-image-create
DIB_DEBUG_TRACE. All scripts have a stanza added to detect this and
turn on tracing. Any other tracing methods are rolled into this. So
the standard header is
---
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
set -x
fi
set -eu
set -o pipefail
---
Multiple -x options can be specified to dib-create-image, which
increases the value of DIB_DEBUG_TRACE. If script authors feel their
script should only trace at higher levels, they should modify the
"-gt" value. If they feel it should trace by default, they can modify
the default value also.
Changes to pachset 16 : scripts which currently trace themselves by
default have retained this behaviour with DIB_DEBUG_TRACE defaulting
to "1". This was done by running [1] on patch set 15. See the thread
beginning at [2]
dib-lint is also updated to look for the variable being matched.
[1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html
Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0
Current iso element uses 'search --file' to find the
grub root. This is a wrong approach as it may find
some other partition containing /vmlinuz. Instead modify
it to search for grub root by the label of ISO image.
Closes-Bug: 1384826
Change-Id: Id4217be3420597bed2f80a96788928259ec91582
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
