To comply with the new hacking>=0.8.0,<0.9 requirements,
assertEqual is used instead of assertEquals which has been deprecated,
giving the error H234.
Change-Id: I3cbef1353260aec1502114010e12d0e507376389
The command `sudo rmdir $TARGET_ROOT/lost+found` will fail
if `$TARGET_ROOT/lost+found` directory doesn't exist,
e.g. when you use non-default image.
Fixes bug #1245856
Change-Id: I48c8f2f201b29912a726249023ca7d20893cc958
These are different tftp implementations, tftpd-hpa and tftpd-server are
equivalent, this mapping was added in a previous commit.
Change-Id: Idd1f554d4ee8e1d3c515d5f2f191e90abe0ff396
Now that we have moved onto neutron-dhcp-agent. dracut-network is no
longer needed, infact it was getting in the way. Dracut wasn't
requesting the classless-static-routes dhcp parameter but was
configuring networking. Removing this causes the network service to
redo dhcp and set the appropriate static route (specifically so
overcloud nodes are routed to the correct metadata server). This element
is still required for undercloud nodes so needs to be included there.
Change-Id: Ic23560164aff7791dd87ed2c3ad008efd248ae93
This will be needed by a patch I'll be submitting to t-e-i to
change the tftp implementation used by ubuntu, so that both
Ubuntu and Fedora can use the same implementation.
Change-Id: Ie9581265dfa2c37342e01162fe580b1948dd3e03
We need this for the Horizon element (which should work both on debian and
fedora-based distros).
Change-Id: I3a1dacbd1823abe051ba977b92b67ed27423f405
Signed-off-by: Tomas Sedovic <tsedovic@redhat.com>
I am getting a lot of http 404's from Fedora mirrors, in particular in
the US. Alternatively we could get cache-url to use previously existing
files if they exist and there is an error but this may not be the
correct thing todo in all cases.
So for now we do a retry if HTTP 404 is returned to the request for a
Fedora image.
Change-Id: I7634aeac3bdfe6930fafe6d276186c09fc8587b5
Commit 0210be22ae introduced the
possibility of basename being called on an empty string. Because
that can happen in normal operation (such as an x86_64 kernel,
in which case the PAE check will find nothing), don't allow the
basename error to kill the script. Also ignore failures in the
second basename call so the proper error message is echoed.
Change-Id: I38a18af09ab24fda9c98cbf3ace8fd7acc6faef5
When picking the latest version of the kernel on i386 we should prioritize
PAE kernels. Debug kernels will be ignored.
Change-Id: Ic0fc5907074ee2a5ddfbbb1db2f1c8a6060cae9f
Related-Bug: #1240873
disk-image-get-kernel picks the wrong version of kernel and initramfs
if there's a PAE and non-PAE version present. Only affects i386 images.
Change-Id: I06e08fdf038988759b620f549261499cb0a69b34
Closes-Bug: #1240873
We now forcibly remove all framebuffer video drivers from ramdisks, as
part of our ongoing effort to keep every kernel we boot, in text mode,
so it can be more easily intercepted by LOM hardware, nova console
logging, etc.
Fixes-Bug: #1178409
Change-Id: Ia72211c97c03c3f60eb9a1483297fe587de51f0b
If the /etc/init drectory gets created on Fedora, it causes
os-svc-daemon to add upstart init scripts instead of systemd.
As a result none of the openstack services can start.
Partial-Bug: #1239880
Change-Id: Iec317baa3eb9ff651fa66c582d2f614993cde45e
For some reason we are adding CR's to/etc/network/interfaces, but it
does not require them. They are a bit annoying to see in an editor and
serve no known purpose there.
Change-Id: I9aeeff5533f418f09fcf33edd42e5d85cd486d23
Previously dhcp-all-interfaces was only blocking the first network
interface to come up. We add an instance stanza to make it run one
instance of generate-interfaces-file per interface. We then use flock to
serialize runs of generate-interfaces-file.
Fixes bug #1233577
Change-Id: Ib16bed6b37ce0789e315ef57e05ac561470a6f2a
Ifquery does not print anything for interfaces which only have a single
iface line. It does, however, return non-zero if the interface is not
configured at all, so we can use that to indicate whether or not there
is a configuration.
Fixes bug #1233579
Change-Id: Ia2fdafbea57e806eba99ae8ddaf395ebdcc306e1
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
Commit c7d80dd (Cleanup mount points automatically) removed the unmount
of $TMP_MOUNT_PATH/tmp/ccache in run_d_in_target() and moved the
"rm /tmp/ccache" to elements/base/finalise.d/02-remove-ccache. There
are two problems with this:
1) Not unmounting at the end of run_d_in_target() results in tmp/ccache
being bind mounted muliple times on top of itself (three times, if you
just run `disk-image-create base`). It is eventually unmounted, but
somehow the auto unmount code is confused, and tries to unmount it
one more time than it was mounted, which results in an error like
"umount: /tmp/image.THQkZxQa/mnt/tmp/ccache: not mounted".
This doesn't actually break anything, but it's a little messy.
2) "rm /tmp/ccache" in elements/base/finalise.d/02-remove-ccache never
succeeds in removing /tmp/ccache, because that hook is invoked by
run_d_in_target(), *while* /tmp/ccache is mounted.
This present commit solves the above by moving the ccache setup glue out
of img-functions and into the base element's root.d. This has the
following implications:
1) lib/img-functions is a little cleaner.
2) /tmp/ccache is available in the chroot during the root, extra-data,
pre-install, install and post-install stages. It is not available
during block-device, finalise and cleanup stages as it will have been
automatically unmounted by then.
3) /tmp/ccache won't be setup if you're building an image that doesn't
include the base element.
Change-Id: Ief4c0a6f4ec622db6c6f652776215684178d8943
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
