Add a note covering what we've discovered about creating RAX/Xenserver
compatible images over the last few days.
Change-Id: Iffd9dab1ca54f27390ec7850093e828ca7576e98
Add a new environment variable $DIB_GZIP_BIN allowing builders to
specify a different gzip (such as pigz) to be used when compressing
tgz images.
Change-Id: Ifb617568140a149e2fda241e07ff8a59429e6697
Use openSUSE 15.1 as default, which is the latest released stable
openSUSE release.
Remove leftovers for unmaintained openSUSE 42.2 images.
Depends-On: https://review.opendev.org/#/c/660126/
Change-Id: I0b204b7b3d7ae74b6749320b3bfe1ca89d154ebb
I want to use the new --image-extra-size flag[1] but my use-case
calls for megabyte granularity of this value. Rather than adding
60% to an 800MB image, maybe I only want to add 100 or 200MB, etc.
[1] https://review.opendev.org/#/c/655127/
Change-Id: I8fb9685d60ebb1260d5efcf03c5c23c561c24384
Use openSUSE 15.0 as default, which is the latest released stable
openSUSE release. Switch to https for accessing download.o.org
as encrypted transfers should be used by default.
Remove leftovers for definitely unmaintained openSUSE 13.x images
and split into old/new leap style versioning scheme for clarity.
Change-Id: Iab129eeee2b1a2563f0f0d2cb17bbad57c068e38
Currently diskimage-builder supports two ways to specify the image
size. One is defining a fixed image size using DIB_IMAGE_SIZE, the
other one is auto-detection while adding a security margin of 60% as
free space. This means when building larger images (e.g. >100GB) with
unknown size upfront we end up with much wasted space, IO and network
traffic when uploading the images to several cloud providers. This can
be optimized by adding a third way by defining DIB_IMAGE_EXTRA_SIZE to
specify the free space in GB. This makes it possible to easily build
images of varying sizes while still minimizing the overhead by keeping
the free space constant to e.g. 1GB.
Change-Id: I114c739d11d0cfe3b8d8abc6df5ff989edfb67f2
In many cases, the statically sized 64MB journal is far below the
e2fstools default calculation[0] which calls for a 64MB journal only
on filesystems smaller than 16GB. On bare metal in particular, the
correct default journal size will often be in the 512MB-1GB range.
Since we cannot know what the target system is, this should be a
tunable parameter that the user can set depending on the intended
image usage.
Add a DIB_JOURNAL_SIZE envvar and --mkfs-journal-size parameter
to the image creation so users can override the default journal
size.
[0] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/mkjournal.c#n333
Change-Id: I65fa13a088eecdfe61636678578577ea2cfb3c0c
These options have always been a bit of a mess since v2 when we added
all the block-device flexibility. Add some explicit documentation to
try and help explain the relationship between these options and the
block-device config.
Change-Id: I49affcbef868d644f673b833bef8310cf25cfd0f
The non-encrypted urls are just redirecting to https, so we
can save one roundtrip by linking the encrypted versions directly.
Change-Id: I88fe8b8c8ccfb5471f59f7898a69bf62cb6cfcaf
Update builds to Fedora 29. Remove the openstack gate CI mirror
workaround for pre-28 versions as they're not building in the gate any
more.
Change-Id: Ia6a8ae8d66d69f6add39e571043328e7274ba26c
Move several parts of the "install_test_deps.sh" script into the more
standard bindep.txt. This list is intentionally restricted as a first
step.
Developer documentation is updated to use bindep and clarified
slightly.
Change-Id: I7520902dc324d920a0c7c44a2d35fe49f9b05614
While trying to get docker image pre-caching to work we couldn't get a
docker daeomon to run within the chrooted environment. However we got
docker running with the help of bwrap outside of the chrooted
environment. The only option so far for this is the block-device.d
phase. But this has the problem that it runs after the image size has
been calculated. This leads to broken builds if the docker images
being pulled are big.
This can be solved by adding a post-root.d phase that runs outside the
chroot but before the image size calculation.
Change-Id: I36c2a81e2d9f5069f18ce5b0d52c5f1c7212c3ae
This updates diskimage-builder to support current Fedora releases (27
and 28) and removes support for Fedora 26 which is EOL as of June
2018.
Change-Id: I602b22ed4d5397b39dc1eef67964f6fbdcd93060
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
In exploring Gentoo caching, it was realised that we have no way to
bind mount the cache into the finalised image for the finalise.d
phases.
By adding a pre-finalise.d phase that runs outside the chroot, we can
mount outside things into the hierarchy at $TMP_BUILD_DIR/mnt which
are then seen by the in-chroot finalise.d phase.
This is similar to the pre-install phase
Change-Id: I9d782994843383ddf90f62c40498af9925fd9558
Some minor things after looking at these parts.
The dib-run-parts element doesn't do any of the copying any more, so
these comments are wrong.
The reason for the multiple mounts in the bind mount was non-obvious
to modern eyes (as util-linux has handled this for some time).
Formatting fix for the rst
Change-Id: Idb4c9ff32c49aced2c68a5c905bf7a8b2832a5a2
Make clear to where in the chroot the contents of
`$TMP_HOOKS_PATH` will be available.
Change-Id: I4b9d20f7ec1c317eb61da44bfd05242dd45263c4
Co-Authored-By: Elyezer Rezende <erezende@redhat.com>
systemd-resolved has a new behaviour in bionic, in that if there is no
/etc/resolv.conf file when it installs, it assumes it is a fresh
system and makes /etc/resolf.conf a symlink into its compatability
files.
dib ends up saving & restoring whatever /etc/resolv.conf we have after
the inital chroot creation, which may not be what we want -- in the
above case it restores the system-resolved symlink. For
openstack-infra, we use unbound and want simply "127.0.0.1" in a
/etc/resolv.conf file [1].
Formalise the ability to save specific contents into the final image.
Add documentation, and a note in the code that it's an external
interface.
I would have preferred to namespace the .ORIG file with DIB_ or
similar, but this unofficial interface has already escaped into the
wild. Leave it as is for simplicity.
[1] Note that systemd-resolved will obey /etc/resolv.conf as you would
expect, if file exists.
Change-Id: Ie0e97d8072e2b21a54b053fa6fb07b62960c686d
Whilst working on the Reproducible Builds effort [0], the team noticed
that diskimage-builder could not be built reproducibly as it iterates
over XML elements in a non-deterministic order when generating the
documentation. This patch sorts the elements, and is a forward of the
patch sent to the Debian BTS [1].
[0] https://reproducible-builds.org/
[1] https://bugs.debian.org/892020
Change-Id: I40011514a135bc50383b072ab83c7f91689bad5a
This moves the block-device default out of the "vm" element and into a
selection of other elements. There's "mbr" which retains the status
quo. There's an EFI version that has the boot/grub partitions as
required. In between there's the GPT only version, which is useful
for architectures like power without EFI, but still want possible
larger disks using GPT.
Change-Id: I4a566a97d073fc0dda0ab2494ac988fe015800a9
This adds support for a GPT label type to the partitioning code. This
is relatively straight-forward translation of the partition config
into a sgparted command-line and subsequent call.
A unit test is added based on a working GPT/EFI configuration and the
fedora-minimal functional test is updated to build a single-partition
GPT based using the new block-device-gpt override element. See notes
in the sample configuration files about partition requirements and
types.
Documentation has been updated.
Co-Authored-By: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Change-Id: I6b819a8071389e7e4eb4874ff7750bd192695ff2
This updates diskimage-builder to support current Fedora releases (26
and 27) and removes support for Fedora 25 which is EOL as of December
12, 2017.
Change-Id: I227a607c6c468cc8b7bb154a189e9c8ce2021192
s390x architecture uses zipl as bootloader. When used in combination
with the vm element it replaces the existing bootloader element.
It's mandatory for s390x vm images.
Use cases
---------
* Allow users to create s390x images that run on nova with s390x
libvirt/kvm backend
* Building nodepool images for s390x third party CI
Supported Distros
-----------------
The following listing shows all Distros that officially support
s390x and how those Distros are supported in DIB with this patch.
* SLES - not supported (SLES is not supported in DIB)
* RHEL - not suppoprted (RHEL is not supported as KVM guest on s390x,
therefore there's no rhel7 qcow image for s390x available
like it is for other archictectures)
* Ubuntu - supported
Ubuntu images can for example be built using the following commands:
$ disk-image-create ubuntu-minimal zipl vm
$ disk-image-create ubuntu-minimal zipl
$ disk-image-create ubuntu zipl vm
Testing
-------
Cross architecture building of s390x images is not supported so far.
The plan is to set up a ThirdParty CI that builds the image for s390x and
provides the logs.
Co-Authored-By: Andreas Scheuring <andreas.scheuring@de.ibm.com>
Co-Authored-By: Holger Smolinsky <holger@smolinski.name>
Co-Authored-By: Zhiguo Deng <bjzgdeng@linux.vnet.ibm.com>
Co-Authored-By: Arne Recknagel <arne.recknagel@hotmail.com>
Closes-Bug: #1730641
Change-Id: I576e7edda68da12e97c60af38f457915efe7b934
When using volumes, booting from them will need that the ramdisk
image used has support for that. In case the lvm module is not
included, mention the need of adding dracut-regenerate in the
elements that are needed.
Change-Id: I6e1f618dcfc5ef3be01c83904ffe6dd33db72bb7
Partially-Fixes-Bug: #1715686
This provides a basic LVM support to dib-block-device.
Co-Authored-By: Ian Wienand <iwienand@redhat.com>
Change-Id: Ibd624d9f95ee68b20a15891f639ddd5b3188cdf9
Testing on a ubuntu cloud image, the build is not possible
because it is missing the kpartx dependency. Adding that
as a requirement, when producing images with partitions.
Change-Id: I0c8f39b5233dd450d8130735ed801bbed6bca0e9
The MBR Partition Table Entry (PTE) allows one to specify many
possible partition types and one of the benefits of this is being able
to specify the CHS variant or the LBA variant.
By default, LBA only creates partitions of type 0x83 (of course,
that's only because the documentation doesn't tell you how to make it
do anything else).
I will take up Ian's suggestion in patch set 2 for a more rigorous
test in an independent patch set.
Change-Id: If3068535980eac2e58d4025444c65147a8c7fedc
Closes-Bug:#1703352
