Azure RHUI and BYOS images use the respective BYOS / RHUI default image
configuration, inheriting the defaults from a common configuration. The
Azure SAP RHUI image was incorrectly using the common configuration and
was not inheriting any settings from the RHUI configuration. As a
result, the Azure SAP RHUI image was missing the following
configuration:
- Required GPG keys were not imported from the file system as part of
image build.
- No RHSM configuration was applied at all.
Add "Rhui" to the image type definition, to make it explicit that it is
RHUI-based. Make sure that the image type default configuration is based
on the common RHUI configuration. Regenerate affected image manifests.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
`authselect-compat-1.2.5-2.el9_1` package is currently missing in AWS
RHUI el9 AppStream repositories, which makes `dnf upgrade` fail on
RHEL-9.1. This is a RHUI-specific issue, since the package is available
in CDN repos.
In order to workaround the issue for now, `authselect-compat` needs to
be removed as part of the upgrade in order for it to succeed. Use
`--allowerasing` instead of just removing the issue, because this will
ensure that `authselect-compat` will be upgraded just fine, once the
issue is resolved.
Fix the issue in the CI script that builds the image using Packer, as
well as the Ansible playbook used by Packer to build the image.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Our 'customize' test manifests include an option to disable the
bluetooth.service. Originally this option was added for image types
that included bluez in their default package set (Fedora IoT commit) but
it was later copied to the qcow2 image type as a way of testing
customizations.
Until recently, building these caused no issues. On distros with more
recent versions of systemd, disabling a non-existent service causes an
error and these manifests fail to build.
Added the 'bluez' package to all manifests that include the 'disable
bluetooth.service' customization and updated the manifests. These
should all be buildable now.
The default value for the `os.FileMode` is zero, but the actual default
value used by the stage if no value is specified in the options is
`0777`. By using the pointer, we'll allow one to specify `0000`
permissions as a value which won't be omitted from the stage options.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for `exist_ok` stage option added as part of
PR#1224 [1], which allows to gracefully handle existence of a directory
path specified to the stage.
This will be helpful when creating custom directories in the image via
customizations, because one can't know in advance whether the directory
path won't be created by a package installed in the image.
Not bumping the requires on osbuild, because this new option is not yet
used by any image definition or customization.
[1] https://github.com/osbuild/osbuild/pull/1224
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The stage supports a `parents` property in stage path options, which
allows one to auto-create any parent directories as needed.
Add the property to stage options implementation.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The plain `Path` name was a bit unfortunate, since it was specific to
the `mkdir` stage, but it was used outside of the `osbuild` package as
`osbuild.Path` which was making a wrong impression of it being a generic
path structure. This is not true.
Rename the structure to contain the stage name.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Since composer is not updated into these distributions, it's safe to use
a newer version of osbuild on them without the risk of releasing a
composer version which would require an unreleased osbuild version.
Every image type defines a list of build pipeline names and a list of
payload pipeline names. These should match the names of the pipelines
that will exist in the manifest when it's generated. They should match
exactly, otherwise issues can occur when reading the metadata from an
osbuild result. The cloud API needs to know the names of the pipelines
and specifically the name of the build pipeline and the payload pipeline
in order to differentiated between build and payload packages in the
metadata.
This new test generates every manifest, parses it into a minimal struct,
and compares the pipeline names with the ones reported statically on the
image type definition.
The format-request-map is updated to remove the override for the
customized qcow for rhel-8.
The rhel-8 manifests are now identical to the rhel-87 counterparts.
- repositories/: add google-compute-engine and google-cloud-sdk repos to
package repositories.
- test/data/repositories/: add rt, rhui, and rhui-azure to test
repositories.
- test-case-generators/: update unversioned rhel-8 repos to point to
RHEL 8.7 snapshots.
Image types no longer report their chains. Instead, pipelines report
their packages and chains and blueprint packages are added to the
workload.
The distro.ImageType interface retains the PackageSetsChains() methods
for RHEL 7 until that is rewritten as well.
The osbuild-dnf-json-test doesn't use the PackageSetsChains() method
anymore. Instead, since it only test the centos-8 qcow2 image, it
hardcodes the expected package set names.
Release repositories (in repositories/) for RHEL 9 are the CDN repos
without a minor release, which should always track GA.
Test repositories (in test/data/ and test-case-generators/) point to
RHEL 9.1, the current GA.
The python3-toml package is called python3-pytoml in RHEL 8, so the name
must be replaced before depsolving. The package is defined in
manifest/os.go which does not have access to the distribution name or
version.
This solution is a temporary workaround. The future solution should
depend on distributions resolving package names based on required
features.
Override the kernel-rt test case for CS8 with kernel-rt-core.
The kernel-rt package resolves to kernel-rt-core (no kernel-rt
metapackage exists).
More details can be found at https://github.com/osbuild/osbuild-composer/issues/3211
Using the same pipeline functions as Fedora and RHEL 9 and copied the
image function from RHEL 9. The most notable change is the replacment
of the deprecated bootiso.mono stage with the more granular stages, just
like with the image installer.
Using the same pipeline functions as Fedora and RHEL 9 and copied the
image function from RHEL 9. The most notable change is the replacement
of the deprecated bootiso.mono stage with the more granular stages.
Using the same pipeline code as RHEL 9 and Fedora introduces the
following changes to the image:
- ostree.config: moved and uses the stage mount instead of the old
stage-specific options.
- lock root password like we do in Fedora and RHEL 9.
- set keymap to us and locale to C.UTF-8 like in Fedora and RHEL 9.
- grub2 contains kernel options and unified set to true. This stage
also now uses the ostree mount options to set up the deployment when
running.
The gceX86 platform embeds the X86 platform and overrides the
GetPackages() method to exclude the grub2-pc package.
The gce image is built as UEFI only, does not include 'grub2-pc', but we
enable BIOS in the platform config for all the other side-effects: grub
config options and grub2.inst stage.
See the image type documentation for more information:
d12d9674d6/image-types/rhel8/google-gce.md (rhel-8-byosrhui--rhel-9-byos-image-differences-compared-to-googles-image)
Changes:
- Remove unneeded RPMs from the build root.
- /usr/bin/tar removed from the selinux stage.
- Changed order of the rhsm stage. This will not affect functionality.
Changes:
- Removed unneeded RPMs from the build root.
- /usr/bin/tar removed from selinux stage.
- Changed order of the rhsm stage. This will not affect functionality.
