The fedora element downloads the latest available image so presumably
will jump to F20 once available. Probably causing several days (weeks?)
of busted stuff. Of course it will be impossible to know when all users
of the elements are ready to switch but the least we can do is allow a
little time as a buffer.
This commit ties it down to a specific version which can then be updated
when the consumers of this element are ready. This allso follows the
same pattern as the ubuntu element.
Change-Id: I15c8e15a66e8af1bd152c27144acbc55af9da88e
When extracting the base image without --numeric-owner, user and group
names in the tarball are mapped to uid/gid by the host. This can cause
problems when building an image for some other distro than you're
running yourself. For example, building an Ubuntu image on openSUSE
ends up with /var/cache/man in the image owned by 'proxy' (uid 13)
instead of 'man' (uid 6), because the host (openSUSE) uses uid 13 for
the 'man' user. This particular man/proxy discrepancy results in
"fopen: Permission denied" errors when apt-get does its "Processing
triggers for man-db" thing in the Ubuntu system. I wouldn't be
surprised if there were other kinks caused by this uid/gid mapping
discrepancy too, but that's the one I found so far.
The same thing can also happen with Fedora, but seems to be less likely,
or at least less obvious to me when building Fedora images on openSUSE.
But, IMO, it's better to be safe and just use --numeric-owner on all
base image untarring outside the chroot.
Change-Id: I9da5ac66dd182e7278fe4fee932093f61d35673a
The code to handle unregister of RHEL subscriptions was buggy and
broke if no subscription credentials were supplied.
Change-Id: Iac29c45f207725e31eac6487a87367fcd3d34d49
the problem is that the journal isn't large enough to allow online
resizing. Solution is straight forward. So the file system can be
resized successfully to disk size specified in flavor.
Fixes bug #1233008
Change-Id: Ie84fb8aea8d334706574d1a8006ec9eaee5bb5be
My previous attempt at forcing the mellanox module to load was
completely bogus. This should not be (although I lack hardware to be
100% sure).
Change-Id: I22ff88181c9c9f0c024e021eeb7f16d79715241a
Closes-Bug: #1233949
In cases where servers ignore the Modified time, curl cancels the
download, outputs a http 200 and leaves the output file untouched, we
don't want this empty file.
Fixes bug #1234926
Change-Id: I05b0dd95dcd53ca50d88ec07f2f1ee9958b6adb7
Cloud-init needs to query the metadata server after the network
interfaces are configured. The upstart job "cloud-init-nonet" is
specifically in place to provide a hook to block cloud-init from
running while we rearrange network interface configurations.
Fixes bug #1233577
Change-Id: Ib5cf75d858fdb670b2abcc082e912c4644d6b169
When LC_NUMERIC is set to a format that doesn't use a decimal point,
`printf` will fail.
Change-Id: Ie6c4d075928f47b17cc413d537fc31c9d0734bdb
Signed-off-by: Tomas Sedovic <tsedovic@redhat.com>
The specifically desired change is the one to setup.py which removes the
reference to d2to1. d2to1 is very undesirable to consume due to its
explicit dependency on distribute that is still unfixed. While we're
doing it, go ahead and do the full update.py from requirements.txt to
reduce later churn.
Change-Id: Ia862337b904ba021db8fc21cb21b886f948bd3fc
Print a message and pause the build for 10 seconds to ensure interactive
users see the message.
Fixes bug #1212080
Change-Id: Ia388a54892c479e428b0ed7b8c70d64d65010e21
* .../locale/diskimage_builder.pot
* .../locale/en/LC_MESSAGES/diskimage_builder.po: Correct the
project name mentioned in the translation comment headers to avoid
downstream licensing confusion.
Change-Id: I6af9f2b3cda7462e21d22ff534e762381e6c73f5
DIB_IMAGE_CACHE will be a user override for the location where images
are cached. Default location is ~/.cache/image-create
Change-Id: I3e9b9f970864d555c9ec9436344b53f6d3d66dfa
This package recently caused us some very large headaches when it
was updated for a security issue. It is completely unnecessary and
should be removed.
Note that we have recommended that it be removed from the cloud images
in launchpad bug #1227425.
fixes bug #1227420
Change-Id: Ic0d4efa7b44c46271d19576f5191c9421d07c015
A problem with unmounting the dev filesystem in Ubuntu images caused
the umount of the /dev bind mount to fail, which left it there to be
removed during the mv -t step, causing the build host's /dev to be
wiped out.
The lazy umount will detach it from the filesystem hierarchy and then
clean up the mount reference later.
Change-Id: I8f8cea857c445fb0b4fd02bc063722fb1553c947
OpenStack runs git.openstack.org which is more reliable and responsive
when projects operate within OpenStack Infra. Replace all of the
references to github with referneces to git.openstack.org.
Change-Id: Ib3ece85aba6451801487b0bdbd83147e39d9e155
Changing the grub config makes no sense in a build not heading for a vm
and may fail because grub is removed from images not including the vm
element. Forcing textmode for those images would be better done in nova.
Change-Id: I1c5b89e551e62df2463200b1889cb2342498c7dd
Boots into the new image kernel once baremetal-deploy-helper signals
it is finished using kexec utilities.
Change-Id: I705787cc394ef14200d80404ee497762ab79b452
In some cases cache-url fails when downloading an image and leaves
an empty cached file. qemu-img then fails with "Wrong medium type"
error on next run.
Change-Id: I23e91c52094f27248cf8452f192ad63646051190
When uninstalling grub2, leave all its dependencies
including grub2-tools installed to minimise the number of packages
which need to be installed in the finalise stage.
Since the yum cache is unmounted during finalise, installing
grub2 in finalise is slowed by re-populating the yum cache.
This change copies the grub2 rpm out of the yum cache so it can be installed
from file during finalise.
This should prevent disk becoming full during finalise on Fedora.
Closes-Bug: #1217185
Change-Id: If095adc4abb52a19a3aa0b1caebfb3e4d8f605ef
This option does not exist on RHEL hosts and matches what is
currently present in elements/rhel/root.d/10-rhel-cloud-image.
Change-Id: I578233c1f37d035c67600fc60e7c4eb4ff75cbb3
For example if there are following kernels in undercloud/overcloud
image:
/boot/vmlinuz-3.9.5-301.fc19.i686.PAE
/boot/vmlinuz-3.10.10-200.fc19.i686.PAE
then disk-image-get-kernel picks vmlinuz-3.9.5. It should use the
newest one.
Change-Id: I7bbf06705e85370d66c7dd8a5d4f8d6c93b21c0c
Fixes: bug #1224365
