In https://github.com/osbuild/osbuild/pull/2148, we changed the logic to
generate the volume ID from the data in `/usr/lib/os-release` to sever
the reliance on metadata in the embedded treefile that will no longer
exist.
This had no effect in FCOS, but had an effect in RHCOS, which
went from a volume ID of `rhcos-...` to `rhel-coreos-...`.
This was considered harmless at the time, but in fact ended
up affecting the OpenShift Assisted Image Service. See e.g.
https://github.com/openshift/assisted-image-service/pull/477 which
attempted to adapt that code. But in the end, it felt safer and less
work to just revert back to the previous volume ID. So here we are.
But we still don't want to go back to using the embedded treefile.
Instead, we now have access to the OS name to use as a label on the
container image. This label gets serialized into the aleph during the
creation of the metal image (via the `org.osbuild.ostree.aleph` stage)
which we have access here when mounting the metal image via loopback.
So pick it up from there and use that. But in case it's missing,
fallback to the previous logic rather than hard fail to make this easier
to ratchet in.
The numeric-owner option omits the inclusion of user and group names in
the archive metadata. This is often desirable since name and group
mappings can change the ownership of files during extraction.
The test uses the tarfile module to check that the uname and gname
attributes in the tar archive itself are empty, which is the intended
effect of enabling numeric-owner [1].
RHEL-102854
[1] https://www.gnu.org/software/tar//manual/html_section/Attributes.html
Currently the grub2 menu defaults to the first entry. This adds support
for setting the default to a later entry. The default in the official
boot.iso is entry 1 -- booting with the iso checksum check.
This includes a test for the new behavior.
Currently the grub2 menu defaults to the first entry. This adds support
for setting the default to a later entry. The default in the official
boot.iso is entry 1 -- booting with the iso checksum check.
This includes a test for the new behavior.
On RHEL 9.7+ and on RHEL 10.1+ we need to be able to include a menu that
boots the installer environment with fips=1 on the cmdline. This adds an
optional menu entry controlled by the "fips" boolean.
This also includes a new test for the menus with and without fips
included.
Related: RHEL-104075
On RHEL 9.7+ and on RHEL 10.1+ we need to be able to include a menu that
boots the installer environment with fips=1 on the cmdline. This adds an
optional menu entry controlled by the "fips" boolean.
This also includes a test for the new behavior.
Related: RHEL-104075
On RHEL 9.7+ and on RHEL 10.1+ we need to be able to include a menu that
boots the installer environment with fips=1 on the cmdline. This adds an
optional menu entry controlled by the "fips" boolean.
This also includes a new test for the menus with and without fips
included.
Related: RHEL-104075
When guest additions are not installed in VirtualBox Vagrant boxes then
the default shared `/vagrant` directory must be set to `rsync`,
otherwise Vagrant fails to start as the shared directory cannot be
mounted with the `vboxfs` filesystem.
Let's expand the schema to allow for `synced-folders` (currently only
accepted under the `virtualbox` variant of the schema) to allow setting
the bare subset of relevant options to configure this from `images`.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
This adds support generating a virtualbox vagrant image. It differs from
libvirt by requiring an xml file and a vmdk image.
When the provider is set to libvirt it is required to pass a
`virtualbox` configuration section to this stage which must include the
mac address.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Test that different calls result in different mac addresses (with the
same prefix), also test that when the correct options are passed that
the mac address is returned as is.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Adds a pattern for the mac address, without delimiters; as this is the
direct input for the virtualbox mac address property.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
The MAC address will need to be the same as the one being used by the
Vagrant stage *if* it's being used. This leaves it up to images to
generate the correct MAC address and set it in both places.
When the OVF stage is used separately it's still fine to use a random
MAC address.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Expand the written XML to include information as used by VirtualBox.
This should not affect any other use cases of the OVF document that is
generated and is purely extra information consumed by VirtualBox.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
This stage writes a file to a device using dd. This is a
rewrite/backport of one of the stages in osbuild-auto.
The osbuild-auto stage is used in automotive-image-builder to write
the aboot image to the "boot_a" partition, to allow android boot
systems to boot. We will want similar functionallity in
bootc-image-builder, so it is important to upstream this.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
This is a new stage to be able to write a (subset) of relevant keys into
the `wsl-distribution` configuration file.
The file, and these options, are necessary for the enablement of fancy
logos and experiences in WSL2.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
On Python 3.6 we're getting a *different* error message from other
versions in CI. Let's accept both versions.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
For the terminal_input, terminal_output, and serial variables in the
GRUB_CFG_TEMPLATE, the keys were not set when those variables were not
defined in the options. This caused the template variables to show up
in the final file itself, which could break the config. For example,
the following line was being generated for one of our images:
serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1${terminal_input}${terminal_output}
Setting the keys to an empty string when they're not defined solves the
issue.
Since this is a stage behaviour change, the new behaviour is toggled by
an option that maintains backwards compatibility when not set.
This introduces a new convention of adding a `compat_version` number to
the stage options to control the behaviour. The value defaults to 1,
which is the old (broken) behaviour. Manifest generators should always
set it to 2 to get the correct behaviour.
In Python 3.14 configparser started validating keys. We use hacky bits
to write duplicate keys which means we have delimiters in our keys which
is now no longer allowed.
Let's explicitly turn off key validation for now as suggested by
mhroncok in [1].
[1]: https://github.com/osbuild/osbuild/issues/2109#issuecomment-2964585958
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
In Python 3.14 configparser started validating keys. We use hacky bits
to write duplicate keys which means we have delimiters in our keys which
is now no longer allowed.
Let's explicitly turn off key validation for now as suggested by
mhroncok in [1].
[1]: https://github.com/osbuild/osbuild/issues/2109#issuecomment-2964585958
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Add the ability to exclude files and directories from the erofs
image. This uses the mkfs.erofs --exclude-regex feature, so simple
matches or regexes can be used.
Add the ability to exclude files and directories from the squashfs
image. This uses the mksquashfs -regex -e FILES... feature, so simple
matches or regexes can be used.
This also adds a new test for squashfs, based on the existing test for
erofs.
The `org.osbuild.tar` stage only supports auto compression which is
based on the filename. For several (newer) artifacts such as Vagrant
(`.box`) and WSL (`.wsl`) we want to explicitly give the compression
algorithm.
I've chosen a (few) commonly used compression algorithms. If others are
needed they are one-line followups away.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Add a new %post option to the kickstart stage that supports adding
multiple post blocks to a kickstart file, with all the options supported
by the directive.
The `generic.ins` template uses:
images/kernel.img
images/initrd.img
However, kernel and initrd are currently stored as:
images/pxeboot/vmlinuz
images/pxeboot/initrd.img
This change ensures correct paths are used.
Extend the stage to support setting new options:
- Provisioning.UseCloudInit
- Provisioning.Enabled
Extend the stage test to use them and add a simple stage unit test for
the schema.
Related to https://github.com/osbuild/images/issues/1416
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The refclock directive can be used to specify one or more hardware
reference clocks to be used as a time source. Each refclock line must
specify a driver and a mandatory parameter, in the form:
refclock driver parameter
Drivers can have driver-specific options:
refclock driver parameter:[driver-option,...]
General refclock options can also be specified:
refclock driver parameter:[driver-option,...] [general-option]...
The stage options schema is written so that the "driver" property is an
object that must match one of four schemas corresponding to the four
drivers, each with a "name" property matching the driver name.
Each driver defines its required property and any optional
driver-specific options.
There are more general refclock options supported than the ones defined
in this commit, but we can add them if and when we need them in the
future.
Note that the restriction on the top-level stage options schema is now
lifted and any set of options can be specified. Servers are not
required. However, at least one top-level property is required still.
Docs: https://chrony-project.org/doc/3.4/chrony.conf.html
Support setting the `auto_enable_yum_plugins` option in the `rhsm`
section of `rhsm.conf`.
Add a unit test for the stage schema and also adjust the stage test
manifest.
Related to: https://github.com/osbuild/images/issues/1408
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
We originally required there to be only one kernel modules directory
since we typically only have one kernel installed. Change this check
up a bit since some kernel module RPMs aren't delivering a new kernel
but do deliver kmods that were built against a different kernel.
For example v4l2loopback from https://elrepo.org/
```
bash-5.1# rpm -ql kmod-v4l2loopback
/etc/depmod.d/kmod-v4l2loopback.conf
/lib/modules/5.14.0-427.13.1.el9_4.x86_64
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/extra
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/extra/v4l2loopback
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/extra/v4l2loopback/v4l2loopback.ko
/usr/share/doc/kmod-v4l2loopback-0.12.7
/usr/share/doc/kmod-v4l2loopback-0.12.7/GPL-v2.0.txt
/usr/share/doc/kmod-v4l2loopback-0.12.7/greylist.txt
```
This patch now allows an image built from a Containerfile like the
following to work as input to the live artifacts stage.
```
FROM rhcos
RUN <<EOF
set -eux -o pipefail
dnf install -y https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm
dnf install -y v4l2loopback
dnf clean all
ostree container commit
EOF
```
