AFAICS, use of this was removed with
I7f98a13091056809fedae8a5c8ee10b0ef8bbb2a and I can't see any other
references to it. Correct the comment to describe how it works.
Change-Id: I5123729b7457dcbd4f4a51cff49904f7bd071e9b
Introduce new container image for Rocky Linux, a downstream clone of Red
Hat Enterprise Linux.
Keep non-voting in Check for a while before adding to any gate checks
Signed-off-by: Neil Hanlon <neil@shrug.pw>
Change-Id: Ib383f60bc23b434b400f85c376840a000cafc697
Related-Bug: https://review.opendev.org/805800/
For centos stream, the $releasever is just the major version. Several
of our .repo files are using $releasever in their path, and I think
that 8-stream installs are actually using 8 repos to install from.
For 9-stream, which doesn't have a corresponding 9, we're getting
errors enabling some of the aarch64 tests.
Replace all the $releasever expansions in the .repo files with the
exact version they are being installed for. They don't need to be
generic; we are installing these specific repos for each DIB_RELEASE,
so they don't mix-and-match.
Change-Id: I48d438d8f51280cd060433fc8a67358d8345287f
SUSE dropped OpenStack Cloud in 2019 [1], and as a result, some
OpenStack-related repositories were removed from openSUSE Download and
root filesystem images stopped being provided. This change deprecates
Leap releases before 15.3 and employs the extract-image script. It also
moves the extract-image script to the sysprep element, since now it's
also used by openSUSE-related elements.
Additionally, revert the "Remove opensuse related funtests" change [2]
so that the opensuse element is tested again and set the default Leap
release to 15.3.
[1] https://www.zdnet.com/article/suse-drops-openstacks/
[2] https://review.opendev.org/c/openstack/diskimage-builder/+/824002
Change-Id: I73d6323aa65cee69a55e54bc53ed682f096dfc89
We've moved away from building "stable"/"testing" targets, as they
move over time so you never know what you're building.
These testing targets are unused, remove them to remove confusion.
Change-Id: I2a53f70ed07873b9a408972d2162b6c10b050db5
This does a basic vm build test of bullseye-arm64, which currently is
missing from the ARM64 testing.
To keep runtimes a bit more reasonable, split the job into two parts,
one for deb distros and one for rpm.
Change-Id: I0f28ff92e1b8d08d56b82b392e2cc355d567d007
This change:
- adds a note regarding an error when building focal ubuntu-minimal
images on operating systems with older versions of debootstrap
- adds a reference to where the DIB_RELEASE variable definition can be
found
Closes-Bug: #1941831
Change-Id: Ibc1e04dba0562c4f4909a8cb8af041d9b8ac45c4
This change replaces the call to grub2-switch-to-blscfg with a file
rename to update it to the actual machine-id.
grub2-switch-to-blscfg has issues in some build environments:
- When the build host is EFI boot, it assumes the image is, and
fails when config file /etc/grub2-efi.cfg is missing
- With recent cento9 images and a fedora build host it fails with:
grub2-probe: error: cannot find a device for / (is /dev mounted?)
Change-Id: I74ad800b702f2b491d958555cef8d7c7f63d74ac
In the grub2 element the grub2-efi-x64-modules package
is missing in the centos 9 section, this cause a failure
because grub2 cannot find the neccecary files when
installing the bootloader on EFI systems.
It seems grub2-efi-x64-modules was not included in release
9, this is likely why the block was added initially without
this package. Since it is now there, the Centos 9 specific
block is no longer needed.
Removing the rhel 8 block as well, as it is identical to the
family "redhat" block i.e it is redundant.
Closes-Bug: #1957169
Change-Id: Ia6b0ecf0cd15fb23c6740543940ee513a8602afe
This change removes the uninstall grub2-efi which was required for
prerelease rhel-9 images but now breaks current centos-9-stream
images. A different approach may be required for rhel-9 if the base
image remains different to centos-9-stream (such as populating the
empty /boot/efi partition from the base image)
This change also fixes the detection of whether this is an efi build
to check the block device instead of checking for whether a grub efi
package is installed. This fixes building a centos-9-stream whole-disk
image when package grub2-efi-x64 is installed but a legacy fallback
grub also needs to be installed.
Change-Id: I24baf553e1acd15a66737fc0b2a79d5335e28aa5
Partial-Bug: #1957789
Per the bug mentioned upstream, grub2-mkconfig will currently not set
the kernel options for BLS entries prefixed with a machine-id
different to the running system.
This affects the centos element, as the upstream .qcow2 comes with a
pre-existing BLS entry but a blank machine-id. This only affects
9-stream -- prior releases either don't use BLS or have entries
configured to use a common variable from grubenv which is updated
correctly.
We currently can not end-to-end test this in OpenDev because we run
our functional tests on Ubuntu Focal (they use devstack), whose kernel
can not read the XFS format on the 9-stream .qcow2. This expands the
functional tests (that run on Debian Buster, with a later kernel) to
add the vm element, so the bootloader path is exercised (this requires
a block-device too). This at least runs the bootloader install, we
can confirm the kernel options look right from the dumping provided
the logs.
Change-Id: I327f5e7a95e47905c01138c8c4483f3f03e8efff
The pip_args variable is not initialized when installing pip for
bullseye resulting in an unbound variable error when running
install_python3_pip on that debian version.
This patch fixes the issue moving pip_args inizialization to a common
place.
Change-Id: I1603c97871449b4f73e3062a705d655e9454bf33
A lack of space between package names was causing apt to fail.
[0] I2b75afd310f009ae8614f6ca75bb984b56d25c45
Change-Id: Ia7e005c2f583037ee44a3c364e3b8d79d51e03a2
Debian bullseye has removed python-pip and python-virtualenv
from its repos, let's install only pip and virtualenv python3 modules.
Also split pip installation based on python2 and python3 for
debian-based distributions.
Change-Id: I2b75afd310f009ae8614f6ca75bb984b56d25c45
This reverts I2701260d54cf6bc79f1ac765b512d99d799e8c43,
Idf2a471453c5490d927979fb97aa916418172153 and part of
Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6 which added special flags to
update kernels via grubby.
These changes actually ended up reverting the behaviour on Fedora 35,
which is what led me to investigate what was going on more fully.
All distros still support setting GRUB_DEVICE in /etc/default/grub;
even the BLS based ones (i.e. everything !centos7).
The implementation *is* confusing -- in earlier distros each BLS entry
would refer to the variable $kernelopts; which grub2-mkconfig would
write into /boot/grub2/grubenv. After commit [1] this was reverted,
and the kernel options are directly written into the BLS entry.
But the real problem is this bit from [2]
get_sorted_bls()
{
if ! [ -d "${blsdir}" ] || ! [ -e /etc/machine-id ]; then
return
fi
...
files=($(for bls in ${blsdir}/${machine_id}-*.conf; do
...
}
i.e., to avoid overwriting BLS entries for other OS-boots (?),
grub2-mkconfig will only update those BLS entries that match the
current machine-id.
The problem for DIB is that we are clearing the machine-id early in
finalise.d/01-clear-machine-id, but then running the bootloader update
later in finalise.d/50-bootloader.
The result is that the bootloader entry generated when we installed
the kernel (which guessed at the root= device, etc.) is *not* updated.
Even more annoyingly, the gate doesn't pick this up -- because the
gate tests run on a DIB image that was booted with
"root=LABEL=cloudimg-rootfs" the kernel initially installed with
"install-kernel" (that we never updated) is actually correct. But
this fails when built on a production host.
Thus we don't need any of the explicit grubby updates; these are
reverted here. This moves the machine-id clearing to after the
bootloader setup, which allows grub2-mkconfig to setup the BLS entries
correctly.
[1] 4a742183a3
[2] https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0062-Add-BLS-support-to-grub-mkconfig.patch
Depends-On: https://review.opendev.org/c/zuul/nodepool/+/818705
Change-Id: Ia0e49980eb50eae29a5377d24ef0b31e4d78d346
Patch allow to set path for local image source,
instead download latest or use the cached image.
This permit to build image also in environment without internet access.
re-propose of patch: https://review.opendev.org/c/openstack/diskimage-builder/+/809009
Change-Id: I54395b09af339caee040326b809e8fbf8b0e7d6a
A recent(-ish) change in git [1] has exposed a bug in caching that
appears in one very specific circumstance -- updating the
openstack/openstack super-repo [2].
This repo gets a submodule update every time something is pushed. By
using "--git-dir" while the cwd is one-level above the actual repo we
are confusing [1] which is not finding the submodule directories
correctly and giving us an error:
Could not access submodule 'foo'
for every submodule that has updated between now and the last time we
updated the cache. [3]
The git manual does warn about this
If you just want to run git as if it was started in <path> then use
git -C <path>.
Indeed, that is what we want to do in this path. Modify the calls to
use -C.
[1] 505a276596
[2] https://opendev.org/openstack/openstack/
[3] The result for opendev production is that image builds fail every
time an openstack/* project is checked in; we then race to retry
the build before another commit lands and updates the submodules
again.
Change-Id: Iadb23454e29d8869e11407e1592007b0f0963e17
Refactor things to use explicit names, and put in a trap to cleanup
after any errors.
Currently, if the build/run/export steps fail, it leaves behind images
which eventually clog things to the point podman won't run any more
(see also https://github.com/containers/podman/pull/12233 about errors
seen due to this)
Change-Id: Ib328a07ad67e3f71f379fbf34ae7ef74e212ef1c
