When --offline is set elements should not revalidate cached data. The
ubuntu element had not been updated to match this. SHA checking is
also skipped as we only move a new cached file into place when the
hash matches, and we might download a new hash before updating the
image cache, which would cause persistent --offline failures.
Change-Id: If1a0366b51951a73b7a3ffe23a29a3d910b08938
I missed the getopt parameter and forgot defaults are imported after
option processing. Untested code is broken code!
Change-Id: I133a691909d38e834c204950276a57f4884fc4ed
Complex image builds can download hundreds of MB of data from the
internet with many separate lookups. It would be nice to allow users
to ask for a fast build where those lookups are entirely avoided,
using locally cached resources (where possible). This new interface
allows users to signal to elements that they wish to operate without
updating cached resources, which will in turn allow us to avoid
checking for stale data at all.
As part of this I've also documented where we cache data, so that
things like the ccache cache dir and image cache files are not a
surprise to users.
Change-Id: I27f5de6ceaa4e9c6390721b7c434fe0908df84f5
In the 52-force-text-mode-console hook, gracefully exit when the
/boot/grub2 directory does not exist on the Fedora 19 cloud image
filesystem. By default the Fedora 19 cloud image is using extlinux to boot
the image instead of GRUB. The decision was taken because GRUB is quite
big (would pull in ~30MB of dependencies) and there's very little benefit
in using it because cloud images don't need to cover all the corner cases.
Change-Id: I52723d4d14c21b1787b4c7e0dd21a09cdbdae0d1
If you have an EFI host but the image doesn't have the EFI modules
installed the grub-install command will fail in case the --target
argument is not set. The problem is that the grub-install script will
check whether the /sys/firmware/efi file exists or not to determine if
it's an EFI installation, but this value comes from the host, so this
patch will look for the /sys/firmware/efi file and will also check if
the EFI modules are installed in the image, if not set the --target to
a non-efi platform.
Change-Id: I4481b43e4a8fe4144be9c7eb9d9c618bbb2df21e
In the 51-grub hook, after the GRUB installation, the script will look
for a GRUB configuration file and in case it's not present one will
be generated using the grub-mkconfig command. The reason why it have
to be done is because the new Fedora 19 cloud images is using extlinux
by default.
Change-Id: I80b15b3122698d98ac4d47dc06faf5909a90ab00
Ramdisks are now built inside a chroot which is built by the normal
image build process. Doing so improves our independence of the
precise state of the build host.
This fixes bug 1194055.
Change-Id: Ibc254fbb9e7b404b5f38c1b35bcde8a4136e8e28
Previously debconf was used and thus this only worked on dpkg based
systems. Now we can support any system that runs a reasonably recent
cloud-init.
Change-Id: I1397aefb3af400adcfd98f858c5a32fad2b584b5
Latest Fedora cloud images are available here
http://cloud.fedoraproject.org/
With this change, when a Fedora version comes up,
d-i-b will point to it automatically.
Fixes 1199237
(Also, thanks to Lucas Gomes for testing.)
Change-Id: Ifcb8a48f3baf3ef841f00e6a20c6fd9f79fea129
Many python extensions are built from source each time an image is
built. Repeating these is wasteful, so ccache is employed to eliminate
that waste. A cache dir outside the chroot is used to speed up
subsequent image builds.
Change-Id: Ib73563ddbe5f3be7454bfc54ab91cedb559a1304
Before each phase dib-run-parts will pick these up to setup the
environment for the commands it runs.
Change-Id: I56697d7bc370918d4063eee67a1c35d4988a5359
The URL to download the Fedora 19 images is not persistent anymore,
they are now download from http://download.fedoraproject.org where the
request will be redirected to a different location. Passing the -L option
to the curl command will make it redo the request on the new place and
download the image correctly.
Related to bug #1199237
Change-Id: Ib9b9d65734992e2bf1a6888c5f2eb9de366f8204
On Fedora 19, there is a delay between the time loop0p2
is created to the time it is ready to be mounted.
This patches waits for 5 seconds for /dev/mapper/loop0p2
to be accessible. If it is not ready then the script
exits with status 1.
Fixes: bug #1197340
Change-Id: Iff0cfd0566673799a77500e0e24954f5f3743a17
systemd on Fedora 19 has made /lib/udev/rules.d/50-firmware.rules
optional:
http://lists.freedesktop.org/archives/systemd-devel/2013-March/009708.html
Firmware is now handled by the in-kernel loader.
Added a file exist check for Fedora 19 and any other distros that
may have dropped the rules file. Backwards compatible with existing
distros.
Fixes: bug #1196409
Change-Id: I1d2acf3f88543736d75eb2e8766e83a3da194638
When downloading the base image for the first time, the response
test expression fails with '[: 200: unexpected operator'. This is
caused by using '==' in the test expression, which is not supported
in sh scripts.
Fixes bug 1195030
Change-Id: I66260814cb591371dc5c10f8436f90c2f18d78cf
Add "NONZEROCONF=yes" to /etc/sysconfig/network to prevent
169.254.0.0 route from being created. This route interferes
with fedora baremetal nodes' access to the nova metadata
server at 169.254.169.254.
Change-Id: Iad77abfc97c0eba944680772f233389481a270ff
RAMDISK_ELEMENT is a spurious difference, to merge the code we need
only semantic difference to exist.
Change-Id: I7d38b2457b6fc838d1a536406bb3c34c00f2b1f9
On fedora 18 the package pyOpenSSL is conflicting with one of the
packages needed to build the bootstack image. The problem gets sorted
if you install pyOpenSSL at the beginning of the image building process
and this is what this patch is doing.
Change-Id: I681683b81ad638dfeb690fde1bc7d08a2116aaed
Use the new source-repository interface to git clone
source repository.
Also there was a few thing in this element that needed to be fixed.
o url to the git repo wasn't curren't.
o pip and git are also dependencies that needed to be installed.
Change-Id: Ieb7be6576fc909aa4bba0233b7b81cab03395d76
Git isn't a dependency of this element, but is a dependency of pbr
if you are doing pip install on a git cloned directoy, because this
looks to be a fairly common pattern it makes sense to have git on the
target image.
Change-Id: I49ee3fa4eac493b9dfa379a674ab9b3390cfc89a
Commit cc5ecb4e9c switched from using
run-parts in favor of dib-run-parts.
/usr/local/bin isn't part of PATH on Ubuntu causing
"/usr/sbin/dib-first-boot: line 8: dib-run-parts: command not found".
Change-Id: Ia7e401221add197edf880af82e0148f3ba7d2b9c
Use flake8/hacking, as is standard in other OpenStack projects, but
disable new checks -- they will be enabled in later patches.
Flake8 catches many useful things
http://flake8.readthedocs.org/en/2.0/warnings.html, and hacking enforces
the OpenStack Style guidelines, including things like one import per
line and alphabetical imports in order to make merging easier.
Change-Id: Ib43f7a6790bc17c0b4efdda0a5f891b5a90303c4
The fedora element downloads images too, so we should re-use the caching
code from the ubuntu element.
There doesn't seem to be other examples of code shared between root.d
scripts. In the fedora and dpkg elements we copy install-packages into
the chroot, but that model doesn't apply when we're running scripts
outside of the chroot. Seems sane to just run it directly from the bin/
dir in the temporary hooks directory.
Change-Id: Iaa6aca660042fea323cab4271633a4bdbbc271b8
