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
Cleaning up the apt-sources README to be easier to consume. Also
removing some tripleo references from the README.
Change-Id: I6937fd5cd51288b36890dde214701bcef1d61381
Some elements (such as the manifests element) want to use these
variables. We currently do not consistently export them (IMAGE_NAME is
only exported if you actually specify a name).
Change-Id: I43d17ddcdd7d0ff3cbb4c530caeebb8da915f4ef
Our docs are very developer focused. Lets create a separate user guide
to help new users get started.
Change-Id: I8a03920e6d3306dd0405177875ea55ccb4b40fea
This commit changes the 80-deploy-ironic script of
deploy-ironic element to report back the status of
boot loader install (when boot_option == "local")
using a newly introduced vendorpassthru.
Closes-Bug: 1422723
Change-Id: I9c1d8643be7cb9e273d65ddd791715a5c271fd93
The listing of *-$INSTALL_TYPE-install files currently uses ls, which
errors out when the glob matches no files, thus using true to not fail
it.
Instead, use find to collect the file list, so there is no need to
ignore the command errors.
Change-Id: Ic6888106858df320a1c90a84f1b9ec74d436b9e6
If py34 is run after py2x, it results in a "db type could not be
determined" error. The only current way to avoid that is to run
py34 first.
Change-Id: Id81e127e71ecd04a2ed16ab899d6fbf0d15bfee3
We currently use qemu-img convert with a raw source and dest when
building raw images. We can just mv the file for increased speed.
Change-Id: I3da095cb9ecad7224a121a434a9fb204132bf6df
Not all operating-system elements install cloud-init, but the base
element assumes its existence. Create the directory if it does not
exist.
Change-Id: I4bda8dc5d200825ea0c8163a4e5c44050a45083f
it may happen that if the system where disk-image-create runs is busy,
then the kpartx -l run may leave a stale autodelete loop device.
This is because kpartx -l first adds a new loop device, then does the
listing and removes the loop device. The latter may not end before the
end of the kpartx run, leaving a loop device marked as autodelete.
Such kind of loop device will automatically delete itself, so the
rm -r $WORKING
after
sudo umount -f $WORKING/mnt
in the EXIT trap will fail because $WORKING does not exist anymore.
To prevent this situation, just ask udev to finish its operations,
properly removing the (temporary) loop device.
Change-Id: I12246f3dbe6b5669e698767682a5a142f803823b
RHEL 7 does not ship tgtadm or tgtd so they cannot be used in the
deploy ramdisk. This change separates the tgt-specific parts of
the ramdisk into their own element, and adds a new one that supports
targetcli instead.
For now, the tgt implementation can only be used with traditional
busybox ramdisks and the targetcli one can only be used with dracut.
This is because dracut is primarily used for RHEL right now so it
makes sense to keep the dependencies simple. If there is a future
desire to mix and match the implementations that could be done, but
it would require users to explicitly select between tgt and
targetcli.
Change-Id: I4f99c91016287e08d836095c2f2261de8b45abdc
Co-Authored-By: James Slagle <jslagle@redhat.com>
It is reasonable that elements may need to include additional
kernel modules in a dracut ramdisk. This is done with the
--add-drivers option to dracut, but previously the value passed
was hard-coded.
This change allows an element to put a file containing its desired
drivers in a dracut-drivers.d directory, and the list there will
be added to the list of drivers added. This functions in
essentially the same way as the binary-deps.d directory that
already exists for including additional executables in a ramdisk.
Change-Id: Ie892b908d36c175a469f7cde7dd803ad4b1942b6
This is required on Fedora 21 in order to build some
packages via source. Includes files like:
/usr/lib/rpm/redhat/redhat-hardened-cc1
Specifically this fixed MySQL driver compilation issues on Fedora 21
for source builds.
Change-Id: I459f2203fa145049dda185da952813118193d573
Rework the list as a definition list.
Mark literal code snippets as literal code snippets.
Fix heading typo.
Change-Id: Ie3d393a49914779f12f3075ff2ac2df5ecf78321
Official MariaDB repositories offer the package : MariaDB-Galera-server.
This package has been now ported within Fedora (and also RDO), the
package is now called mariadb-galera-server. Yum install being case
sensitive hence this change.
Change-Id: Icd03877f17d01708b3916578991e42eef30a69e4
As part of the blueprint root-device-hints Ironic will pass some to the
deploy ramdisk some hints about which disk device it should pick to be
root device (the one where the image will be deployed on).
Before the deploy ramdisk would pick the first device it finds, but as the
machine could have more than one SATA, SCSI or IDE disk controllers the
order in which their corresponding device nodes are added is arbitrary
causing devices like /dev/sda and /dev/sdb switching around on each
boot time.
Plus, as people are adding support to build RAID arrays in Ironic we need
a way to tell it to use the just created device to be the root device.
The list of hints that could be passed to the deploy ramdisk so it finds
the right disk is:
* wwn (STRING): unique storage identifier
* serial (STRING): disk serial number
* model (STRING): device identifier
* vendor (STRING): device vendor
* size (INT): The size of the disk in GB
If not hints are passed, the deploy ramdisk will continue to do what it
did before to find the disk.
Change-Id: I8425f593e1a610af5a3697988702603ff218f2de
This commit adds support for uefi localboot in
deploy-ironic element. The change is to mount the efi
system partition (created by Ironic) in /boot/efi.
The corresponding Ironic change is
I00ac31da325676ea4ea1ac4185f5ac3a52c5809a
Implements: blueprint local-boot-support-with-partition-images
Change-Id: Idf7ac5987e14e1d31311834196ca7283deec15c6
