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
Ic68e8c5b839cbc2852326747c68ef89f630f26a3 removed the sudo from the
tar extraction here, meaning that production is failing to create the
chroot. This is hidden in testing because
DIB_CONTAINERFILE_PODMAN_ROOT is set. Make the sudo here
unconditional.
Change-Id: I6e36e3fc65981f85fad12ea2cd10780fde9c37da
CentOS Stream 9 is close to be released, and official mirrors are
already poplated. This patch is adding support to centos-minimal in CS9.
Also enable centos-minimal/[8,9]-stream-build-succeeds tests.
This patch is being tested together with [1] to apply following list of elements:
vm centos-minimal simple-init growroot nodepool-base openstack-repos infra-package-needs
[1] https://review.opendev.org/c/openstack/project-config/+/811442
Change-Id: Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6
The if/elif block added in [0] doesn't work for gentoo, let's hope
that we can get along with an easy fix.
[0] https://review.opendev.org/c/openstack/diskimage-builder/+/804000
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I543e04d2d7efea3e718bae31aa1cc4767bd359f8
This adds 9-stream support to the centos element.
See https://review.opendev.org/q/topic:cs9 for related patches.
Change-Id: Ib80fbd21edb77c25764eff2c0d66e55bde7a90af
We need to update the base reference platform we perform the
functional tests on. Debian bullseye seems like the best choice -- it
is recent enough to last for a while, and will match the
nodepool-builder container environment.
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/814088
Change-Id: Ic68e8c5b839cbc2852326747c68ef89f630f26a3
I'm not aware this element is used/was ever used. It hasn't ever been
updated to Focal. To reduce our testing footprint remove this test,
and note in the element its probably broken.
Change-Id: I17cd3b13948287fe78990cfbe16a22919a329ba9
This reverts commit 1f4fb1d7a5.
This unfortunately wasn't actually tested. Because the image-based
tests run sequentially, a prior failure in the centos-8 job meant the
ubuntu job never ran.
This is failing with
10-cache-ubuntu-tarball: line 28: DIB_LOCAL_IMAGE: unbound variable
There is also a seemingly unused variable DIB_IMAGE_LOCAL_FILE; I'm
not sure what this is doing.
For now revert, and it can be re-proposed with appropriate testing.
Change-Id: I0f3897c90dc863ee04c3295b9cb094f02d8658e3
It looks like upstream have changed this line to "download.example",
breaking our subsitution. Let's do a generic match.
Change-Id: I8e443022a5f239b98ccefe73a9abf8cf259dc8e9
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.
Change-Id: I9422e21c5d0445e31d5a7258aa7310b20e39b929
A custom yum repository can now be configured by defining
`DIB_YUM_REPO_PACKAGE` as a yum available package or a URL to an rpm file.
This package can install repo files with any associated keys and
certificates.
A good example of such a package upstream is rdo-release[1] which
includes multiple repo files, the repo keys, and a root certificate.
This makes these repos impractical to install via DIB_YUM_REPO_CONF.
Downstream, repo packages like this a frequently used to bootstrap
development builds of RHEL with development repos.
[1] https://www.rdoproject.org/repos/rdo-release.rpm
Change-Id: I2832e723998c9bd7635cdf7541a4c20eff6294d2
Fedora 30 and RHEL-8.2 onwards support the Bootloader Spec and use grubby
to manage kernel menu entries and kernel arguments.
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
This change detects if this is a BLS enabled environment, and uses
grubby to set kernel arguments on all kernel entries if it is.
Change-Id: I2701260d54cf6bc79f1ac765b512d99d799e8c43
If the grubenv is regenerated, its changes won't be available to UEFI
boot systems unless the changed grubenv is copied to the EFI
directory.
This change copies the grubenv to the EFI directory when the grub.cfg
is copied.
Change-Id: I512502117a6bf1e6122fdfd8965ca488b4a5bae4
Debian stable security repos is now stable-security, as well as other
versions.
Move the Debian bullseye job from experimental to non-voting check.
Change-Id: I451cacda6573727de9448b5857bed5181850b4ad
The latest Debian bullseye release doesn't provide yum any more, only
DNF. This breaks the minimal builds that are using on-host yum tools
to start the chroot. Probe for yumdownloader, and if it's not there,
use DNF.
Note this requires "dnf download" which may not be packaged. See
I21cfbd3935e48be4b92591ea36c7eed301230753 for a sample work-around
that installs this plugin in the nodepool-builder container.
Change-Id: Ia7f1e4d115cc67c378d865d91af94a07b8cdc6cc
Add openeuler-minimal element and add CI functional tests for both
x86_64 and arm64.
OpenEuler is an open source community driven YUM/DNF distro like
Fedora. It references Fedora and CentOS a lot for the rpm packages
building. So somewhat it can be treated as a redhat family distro
and reuse the YUM/DNF related elements to help build openEuler images.
For more info about openEuler, see: https://openeuler.org/en
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/803413
Change-Id: I3e06e49b524364c3a4edeba8bce7a8c06b9c7b76
This change permits the yum-minimal element to be used in downstream
custom distributions, which may have additional packages containing repo
config or GPG keys needed.
This could also be utilized at a later time to move the
distribution-specific logic in this method to each distribution element
separately.
Change-Id: Ic1434bb2fe7301086cf11ba6bd7f2ee187c5e6c8
The following two channels were migrated to OFTC.
#tripleo
#openstack-dib
Also, the following channel was migrated to Libera Chat[1].
#opensuse-cloud
[1] https://en.opensuse.org/openSUSE:IRC_list
Change-Id: Ia4c729a8d284bbfcbdb3b8621ae29d9be57886f5
Add dnf-plugins-core to the package-installs; this lets things like
"dnf copr" work automatically and is in-line with fedora-minimal base
packages. While we're here, clean up some unneeded packages, and
remove the pkg-map that isn't relevant for Fedora builds.
Change-Id: Iad5a4717bcb55928377cc159b3360b0a70c5c5ac
As noted inline, this works around potential issues by being a strong
indication you are in a container (e.g. [1]). Since nothing should be
changing anything on the host/build system, this is a generically
safer way to operate.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1975588
Change-Id: Ic6802c4ffc2e825f129af10717860a2d1770fe80
There is currently no automated way of growing LVM volumes on boot
like single partition images do with their growroot mechanism. This
lack likely contributes to LVM not being widely used on VM and
baremetal workloads, since growing to the full disk requires workload
knowledge to determine which volumes to grow and by what amount.
The growvols element contributes a growvols python script which can be
run on firstboot (via systemd or cloud-init) or manually via
automation such as ansible. It is also an interactive script which
displays the full list of modifying commands before prompting for
confirmation to run them all.
By default the script will grow the root volume, but arguments allow
any volume to grow by a specified amount, or a percentage of the
available disk space.
Blueprint: whole-disk-default
Change-Id: Idcf774384e56cce03e56c0e19c7d08a768606399
curl's "-v" is a bit too verbose for "-x", especially when what you're
downloading bounces through a few redirects as is common. Turn this
down and put it behind "-xx" or greater.
Change-Id: I6d91166bb237f2a1818cae7532e794ef0f01288b
Element block-device-efi-lvm has been added which is like
block-device-efi but defines an LVM logical group in the root
partition. Three logical volumes are defined in that group, mounted to
/, /var, and /home.
This volume layout will not meet all requirements, but this is more of
an example demonstrating the capability to encourage more usage of
this existing feature.
This is based on the overcloud-partition-uefi element in
tripleo-image-elements, and I believe this capability is too useful to
have the only working example buried in a related project repo.
This change also fixes the element string matching in
_arg_defaults_hack, the 'vm' test was also matching against 'lvm' and
'block-device-efi-lvm' elements. Also the 'block-device-' test now
properly tests for this being the prefix of the block-device element.
This change also makes block-device-efi fsck-passno compliant with the
documentation[1] so that / has value 1 and all other mounts are set to
2.
[1] https://www.man7.org/linux/man-pages/man5/fstab.5.html
Change-Id: If86a0e49186ce5a65cc0084101d31ce59a97b854
Blueprint: whole-disk-default
The bootloader element uses the grub-efi-$arch package to remove already
installed packages (for redhat). The uninstall of a non-installed
package fails with a non-zero exit code on gentoo. The gentoo base
tarball does not include a bootloader and the grub-efi-$arch package is
only used for uninstalls, so zero out the variable to allow bootable
images to be generated.
Change-Id: If8572abd6e19a02f2f63b33d4f83a7054774d7e6
Signed-off-by: Matthew Thode <mthode@mthode.org>
This is a first pass through the bootloader, that removes the extlinux
and syslinux install/cleanup path.
Change-Id: Ifb107796cdb6748430a124bf13ced93db9689bff
As noted inline, the switch to "boot loader spec" grub entries breaks
our setting of the root device. This happened some time ago, and it's
not 100% clear to me why our existing Fedora builds haven't broken on
this. However, the new containerfile based builds do seem to be
hitting this.
Disable it for now.
Change-Id: Ia3472947799bb35ffccfa92937cdd0d68b12a25c
Fedora cloud images have sub-releases in their filename. It is not
exacly clear how this is generated but we do know how we can determine
the greatest programatically.
Change-Id: I7fc56897c681fe037db211c290edcdd23cdd5d5b
This makes the container file element search the active element list
for `containerfiles/${DIB_RELEASE}` for building. This makes it easy
to write wrappers for ubuntu/fedora/etc. containerfile elements.
Change-Id: I68f1d928e54a70bad76985ddd3e156bb5f978b0d
This is a base element which uses a containerfile (Dockerfile) to
build a container image, then the filesystem is extracted from that
image and forms the root of the dib image.
You can add as little or as much to the dockerfile as desired.
Change-Id: I4e821aa2ce7feb8841ef31da56de1a31aa9218b5
With the release of Debian bullseye and later, security updates are
provided in the bullseye-security suite instead of bullseye/updates.
Change-Id: I63580ec96a53e5e8ef8d105e766d838029727917
Currently Debian sets /etc/debian_version to "bullseye/sid" and, due
to a series of issues explained in [1] more fully "lsb_release -c" in
the OpenDev environment doesn't return the distribution code name.
Overriding this to the final release version fixes this.
[1] http://lists.opendev.org/pipermail/service-discuss/2021-April/000222.html
Change-Id: I00c1741dac6ad5f2c4bf855a207f17d8985bc763
Some older distros (like centos8 and xenial) don't support SNI in their
easy_install implementations which are used to install setup_requires
for python packages. PBR is a setup_requires for glean. We work around
this problem when installing glean by preinstalling PBR with pip.
Change-Id: Ie9f5c9ed06954cbe51f23fe8cca0655a931a5201
The rhel-8.4 qcow2 base image already has the grub2-efi-x64 package
installed on its single partition which has files installed to
/boot/efi..., however a partitioned image will have an empty /boot/efi
partition when running 50-bootloader. This means dnf will not install
grub2-efi-x64 when requested and /boot/efi will remain empty.
This commit makes the following changes:
- Refactors redhat bootloader pkg-map for the following:
- Make x86_64/amd64, arm64/aarch64 adjancent so they don't diverge
- Map grub-efi to packages installed to /usr
- Map grub-efi-{arch} to packages installed to /boot/efi
- Removes packages grub-efi-{arch} before installing grub-efi and
grub-efi-{arch}
Change-Id: Ia197feea34f43bd870fed30829b740596e6b2f48
https://review.opendev.org/c/openstack/diskimage-builder/+/785138
adds the support for DIB_DNF_MODULE_STREAMS which is now available
for all Yum based distros.
This patch enhances the docs for using it for all Yum
based distributions.
Signed-off-by: Chandan Kumar (raukadah) <chkumar@redhat.com>
Change-Id: I29e726679c2b675b3c0cd95a3ff48fdad7cd5431
We've noticed that centos8 arm64 images have a root devices of
/dev/mapper/loop7p3 which make sense within a dib image build context
but not at boot time. Dib intends to use labels to set the root device
but when efi is used we end up running grub2-mkconfig against the efi
grub config path before we configure grub to use labels.
Fix this by running grub2-mkconfig after its configuration is set.
This should avoid confusion and complicated paths through the scripts
that configure this for us. We then copy the resulting config to the efi
specific grub.cfg location for platforms that have it.
There is also a small refactoring that is done to try and make the ~3
boot variants more clear:
1) Booting with legacy bios
2) Booting with uefi without a signed shim that directly calls grub
3) Booting with uefi and a signed shim that calls grub
Options 1 and 2 share the /boot/grub*/grub.cfg file. Option 3 needs its
grub.cfg to live alongside distro specific efi target.
Change-Id: Ie9790da9d1bbea58197b37b15a48e77f8a93c1ac
While building cloud images, it is common to set modules
for CentOS and RHEL images. Earlier it was part of rhel-common
which was specific to RHEL OS not for CentOS. Moving it
under yum element as module/stream can be enabled or disabled
via dnf itself.
Signed-off-by: Chandan Kumar (raukadah) <chkumar@redhat.com>
Change-Id: Idc0f277f97e92e4d003f059f01b59f1b5513da34
