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.
Check for valid ipv4 addresses via a regex in the schema and
add matching tests. This will ensure that only valid ipv4
addresses can be entereed in "ip", "gateway" or "nameservers".
Note that libc/kernel accept invalid ipv4 addresses and do
"interesting" things with them. So they accept `127.1` and
turn that into `127.0.0.1` or even `127.256` and turn that
into `127.0.1.0` because 256 overflows into the next segment
(thanks to Simon for poiting this out). If this becomes a
problem and customers rely on invalid ipv4 addresses we will
need to relax the rules but let's start strict and help our
users with more guardrails.
Note that no ipv6 validation via regex is done. The regex
on stackoverflow for validating ipv6 is 660 chars long
and that seems a bit too long for our schemas and putting
and error with that in front of our users.
This commit adds a small stage unit test and most importantly
a comemnt why `devices` is part of the schema (but appears unused).
The reason "devices" is explained by Alex Larsson:
"""
The mounts don't work without devices that have the filesystems.
In sample-images for example, this is typically used like so:
```
type: org.osbuild.ostree.post-copy
devices:
root:
type: org.osbuild.loopback
options:
filename: disk.img
mounts:
- name: root
type: org.osbuild.ext4
source: root
target: /
```
"""
If fs-verity is configured in ostree then ostree will (try to) enable
fs-verity on various repo files. However, in osbuild this will happen
in a separate pipeline, and these files will later be copied to the
final location on the physical filesystem, and any fs-verity status
then is lost.
To support fs-verity we need to run this stage after copying the image
to the filesystem. It uses the ostree "admin post-copy" operation.
which it will re-enable fs-verity as needed.
This adds a new stage that allows you to set the experimental new
`ex-integrity.composefs` option. If set to true, it means that when
deploying from this repository a composefs image will be created.
A value of `maybe` is also supported, which means composefs will only
be created if support is built into ostree.
Support for this was added in ostree 2023.4, earlier versions ignore
this key.
This stage uses the new prefix org.osbuild.experimental. This way
users will not accidentally enable an experimental option, and allows
us (and ostree) some leeway in making changes over time to this
feature.
This stage calls `update-crypto-policies` to set the
policy applicable for the various cryptographic back-ends,
such as SSL/TLS libraries.
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
Link "/proc/self/fd" to "/dev/fd" within the tree
to avoid "'/dev/fd/63': No such file or directory" errors
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
This implements the display mode options `text`, `graphical`,
`cmdline` as an enum with the name `display_mode`.
See PR#1442 for the rational/discussion of this over using
three boolean options.
Thanks to Achilleas and Tom!
This adds a stage to be able to add kernel arguments on a system by
appending to the BLS [1] config directly either in the tree or in
a mount. This is useful on say systems that don't use `grubby` and
thus can't use the org.osbuild.kernel-cmdline stage.
[1] https://freedesktop.org/wiki/Specifications/BootLoaderSpec/
This form of signatures has been (build-time-optionally) supported
since ostree 2020.4 as an alternative to the old gpg signatures. With
the current work on composefs[1] they are becomming more important, as
they will allow verification of the commit (and thus the composefs
image) during boot, giving us a full trusted boot chain all the way
into the ostree userspace.
Note: `ostree sign` used to require libsodium and was thus disabled in
e.g. the Fedora build of ostree. However, recently[2] it is also supported
with openssl, which will let it be more widely used.
[1] https://github.com/ostreedev/ostree/pull/2921
[2] https://github.com/ostreedev/ostree/pull/2922
This stage allows you to create new (random) ed25519 keys as used by
`ostree sign`.
The primary usecase for this is composefs. You can generate a
transient key-pair during the build (unique to the build) that binds
the initrd to the userspace tree.
You put the public key in the initrd, sign the resulting commit with
the private key and then throw away the private key. During boot of a
(secureboot trusted) initrd, we use this public key to validate that
we're booting the right commit.
This is similar to how the transient kernel module signatures work.
It similarly generates a keypair during the kernel rpm build, sign the
modules, throw away the private key and embed the public key in the
kernel binary.
Of course, this stage can also be used to generate keys used for
persistant signatures.
Now that inputs can be relatively easily validated against
the schema this should also be used for all the "good" test
inputs to ensure that all tests test against valid inputs.
