Add or remove the immutable bit to the specified mount directory.
The need we have for this right now is for the CoreOS builds where
the immutable bit being set on an OSTree deployment root doesn't
survive the `cp -a --reflink=auto` in the org.osbuild.copy stage when
being copied from the directory tree into the mounted XFS filesystem
we created on the disk image. Thus we have to workaround this loss
of attribute by applying the attribute directly on the mounted
filesystem from the disk.
Introduce a 'stage_schema' fixture, which will load the stage schema
by the stage name defined in the STAGE_NAME defined in the test module
and optionally provided schema version and return it. If no schema
version is specified, version "2" is assumed. Modify all stage unit
tests to use this fixture, instead of loading the stage schema on their
own.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Introduce a 'stage_module' fixture, which will load the stage module by
its name defined in the test module STAGE_NAME variable. Modify all
stage unit tests to use this fixture, instead of loading the stage
module on their own.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add a simple unit test, which ensures that the `datasource_list` key
is dumped in the configuration file on a single line if defined in
the stage options.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The stage dumps invalid cloud-init configuration, in case the
`datasource_list` key has a value assigned. The value is supposed to be
a list, but cloud-init documentation mandates that the value is always a
single line, with no newlines. This was not true in the past.
Fix#1554
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This commit adds a new `exclude` option to the container-deploy
stage. This is needed when we deploy `bootc` containers that are
used for the buildroot. Here the `/sysroot` dir needs to be
excluded because it has conflicting selinux definitions for
files there and in the normal "root" dir.
See also https://github.com/osbuild/bootc-image-builder/pull/138
It appears to work with the `docker://` prefix as well as the
`registry:` prefix.
```
$ ostree container image list --repo=/ostree/repo
docker://quay.io/fedora/fedora-coreos:rawhide
$
$ ostree container image metadata --repo=/ostree/repo docker://quay.io/fedora/fedora-coreos:rawhide | md5sum
aaf7fa84896358730f0a69c330db31a6 -
$ ostree container image metadata --repo=/ostree/repo registry:quay.io/fedora/fedora-coreos:rawhide | md5sum
aaf7fa84896358730f0a69c330db31a6 -
```
Let's just keep the name unmodified. This also fixes it so that
`registry:` doesn't get prepended to refs that aren't from a registry
like:
```
$ cat /ostree/deploy/rhcos/deploy/3824ff6c279d0f4ef043e80f448eeb0d24269d50e452224a5614f915ee73fb7e.0.origin
[origin]
container-image-reference=ostree-unverified-image:oci-archive:/rhcos-416.92.202401191512-0-ostree.x86_64.ociarchive
$ ostree container image metadata --repo=/ostree/repo oci-archive:/rhcos-416.92.202401191512-0-ostree.x86_64.ociarchive | wc -c
16292
```
The test starts failing because a new version of jsonschema (4.21.0)
changed the error messages for `minProperties: 1`.
To fix this we just use a regex and check for both possible values.
As a drive-by the commit also improves the error output in case
the match is not found.
For ppc64le we need to pass in a partition (i.e. /dev/loop0p1) rather
than the root device (/dev/loop0) to the --device argument of bootupctl.
Let's add a partition field and find the device node based on the user
specified partition.
On ppc64le this would look something like:
```
- type: org.osbuild.bootupd
options:
bios:
device: disk
partition:
mpp-format-int: '{image.layout[''POWERPC-PREP-BOOT''].partnum}'
static-configs: true
deployment:
osname: fedora-coreos
ref: ostree/1/1/0
devices:
disk:
type: org.osbuild.loopback
options:
filename: disk.img
partscan: true
mounts:
- name: root
type: org.osbuild.xfs
source: disk
partition:
mpp-format-int: '{image.layout[''root''].partnum}'
target: /
- name: boot
type: org.osbuild.ext4
source: disk
partition:
mpp-format-int: '{image.layout[''boot''].partnum}'
target: /boot
```
Add the bootupd stage to install GRUB on both BIOS and UEFI systems,
ensuring that your bootloader stays up-to-date.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
The EFI binaries are currently pulled from a hardcoded path in the
buildroot. When moving to containers as buildroots this will no
longer work as they have an alternative layout. This is an easy
"fix" - make the location of the `EFI/` directory configurable.
This allows us set `efi_src_dir` to `/usr/lib/bootupd/updates/EFI/`
and keep our existing `bootc-image-builder` workflow.
Note that this may actually not be the desired solution and instead
we want the new `bootupd`: https://github.com/osbuild/osbuild/pull/1519
This commit ensures that `/var/tmp` is available. Skopeo expects
this dir but the bwrap environment starts with a very minimal
`/var` so `/var/tmp` may not be available.
This commit reworks the `org.osbuild.container-deploy` stage to
not use a tmp storage when mounting the container image. This
is needed because of [0] but it should generally be fine because
inside the stages the real /var is a tmpfs (which is why we
triggered the bug in the first place).
[0] https://github.com/containers/storage/issues/1779
Similar to the aleph file created for builds of FCOS based on ostree
commit inputs, this adds an aleph file that contains information about
the initial deployment of data when the disk image was built
A new stage is preferred here as both the org.osbuild.ostree.deploy
and org.osbuild.ostree.deploy.container stages need an aleph file and
use of the aleph file may depend on the project/product. For example,
right now CoreOS is the only project that uses an aleph file, but others
may want it in the future.
This adds a new key masked_generators, similar to masked_services,
which masks systemd generators from running at boot, by creating
symlinks to /dev/null in /etc/systemd/systemd-generators, as
described in:
https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html#Description
This will be useful for the automotive project, as it allows disabling
of unsupported things like sysv or rc.local legacy support, while
improving boot performance.
The skopeo stage is updated to accommodate two types of
destinations: 'containers-storage' and 'oci'. Now, it can
copy a container image to either a container store or
a directory as per 'Open Container Image Layout
Specification'.
Pytoml is no longer being maintained: https://github.com/avakar/pytoml
The author suggest switching to toml.
We already use the
```
try:
import toml
except ModuleNotFoundError:
import pytoml as toml
```
pattern in stages/org.osbuild.containers.storage.conf so use it in the tests too to prefer "toml" instead of pytoml.
This commit extends the current support for OpenSCAP
tailoring by accepting an array of key/value overrides.
Users will be able to specify override values for specific
rules that will update the value when remediating the
image.
This adds tests for the erofs stage. The tests are slightly different
from the existing tests that run the filesystem utils inside the
stages. Depending on what exactly we want to test we may still need
a run inside the stages. However running this inside a container
should be good enough if we just want to validate that the options
are passed correctly and the file is created.
Erofs is "a lightweight read-only file system"[1]. Imagine squashfs, but with
faster reads.
This commit adds support for creating it. The new stage is heavily inspired by
the squashfs one. I've decided to add all features of mkfs.erofs that looked
useful: All compression types and most of extended options (excluding the
compatibility ones, we can always add them later).
[1]: https://en.wikipedia.org/wiki/EROFS
This is a variation of PR https://github.com/osbuild/osbuild/pull/960
that put the machine-id handling into it's own stage and adds
explicit handling what should happen with it.
For machine-id(5) we essentially want the following three states
implemented:
1. `first-boot: yes` will ensure that /etc/machine-id is
in the "uninitialized" state. This means on boot the systemd
`ConditionFirstBoot` is triggered and a new id in `/etc/machine-id`
is created. This will work for systemd v247+.
2. `first-boot: no` will ensure that /etc/machine-id exists but
is empty. This will trigger the creation of a new machine-id but
will *not* trigger `ConditionFirstBoot`.
3. `first-boot: preserve` will just keep the existing machine-id.
Note that it will error if there is no /etc/machine-id
Note that the `org.osbuild.rpm` will also create a
`{tree}/etc/machine-id` while it runs to ensure that postinst
scripts will not fail that rely on this file. This is an
implementation detail but unfortunately the rpm stage will
leave an empty machine-id file if it was missing. So we cannot
just remove /etc/machine-id because any following rpm stage
would re-create it again (and we cannot change that without
breaking backward compatiblity). Thanks to the special semantic
that a missing /etc/machine-id and an /etc/machine-id with
the `uninitialized` string are equivalent we don't care.
To support systemd versions below v247 we could offer an option
to remove /etc/machine-id. But the downside of this is that
it would only work if the org.osbuild.machine-id stage is after
the rpm stage.
See also the discussion in PR#960.
Thanks to Tom, Christian for the PR and the background.
