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>
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.
The next commit will add a stage test that requires erofs-utils. Let's add it
into the buildroot in a separate commit, so the history is more readable.
For our Fedora CoreOS disk images we set the partition labels (name)
for the partitions. This is also supported using the primitives here
in OSBuild, but it wasn't obvious that I needed to set the name in
the mpp-define-images definition. Let's set the name there, but let's
also allow osbuild-mpp to set the `id`, which is what is used later
to access that partition from the `name` too if `id` isn't set.
This means we allow something like:
- name: BIOS-BOOT
type: 21686148-6449-6E6F-744E-656564454649
bootable: true
uuid: FAC7F1FB-3E8D-4137-A512-961DE09A5549
size: 100
rather than requiring something like:
- id: BIOS-BOOT
name: BIOS-BOOT
type: 21686148-6449-6E6F-744E-656564454649
bootable: true
uuid: FAC7F1FB-3E8D-4137-A512-961DE09A5549
size: 100
Also switch the qcow2 output to be a "qemu" platform image. This
change takes advantage of the recent org.osbuild.kernel-cmdline.bls-append
stage addition to modify kernel arguments in later pipelines.
To get a qemu image output:
- osbuild --output-directory out/ --export qemu test/data/manifests/fedora-coreos-container.json
To get a metal image output:
- osbuild --output-directory out/ --export metal test/data/manifests/fedora-coreos-container.json
With lvm2 the generated fedora fc38 boot image boots in degraded
mode with the following error:
```
[root@localhost ~]# journalctl -u lvm2-monitor.service|more
Nov 13 12:52:04 localhost.localdomain lvm[431]: Failed to create /etc/lvm/devi
ces 2
Nov 13 12:52:04 localhost.localdomain lvm[431]: Failed to set up devices.
Nov 13 12:52:04 localhost.localdomain systemd[1]: lvm2-monitor.service: Main pro
cess exited, code=exited, status=5/NOTINSTALLED
Nov 13 12:52:04 localhost.localdomain systemd[1]: lvm2-monitor.service: Failed w
ith result 'exit-code'.
Nov 13 12:52:04 localhost.localdomain systemd[1]: Failed to start lvm2-monitor.s
ervice - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress p
olling.
```
This breaks the `test_boot.py` which expects the system after booting
in `running` state (from `systemd is-system-running`).
It looks like this is some sort of race with our generated image,
potentially related to selinux, see
https://github.com/lvmteam/lvm2/blob/v2_03_18/lib/device/dev-cache.c#L1842
and note the lines around dm_prepare_selinux_context(). Note
also that `lvm2-monitor.service` runs with `DefaultDependencies=no`
(c.f.
https://github.com/lvmteam/lvm2/blob/v2_03_18/scripts/lvm2_monitoring_systemd_red_hat.service.in#L7)
Given that the official fc38 cloud image does not use lvm2 and that
it's not needed for the boot test this commit simply removes it
from the fedora-boot manifest. This fixes the test.
Authconfig was completely retired from Fedora. In order to keep this stage
covered, this commit changes the test to use CentOS Stream 9, which still
ships this package.
This commit migrates the test to a brand new V2, F38-based manifest. It's
actually based on osbuild-composer interpretation of the Fedora Cloud Base
image.
The items of an array are defined under the `items` key, not under `paths`.
Let's fix this.
Btw, this is possible because JSON Schema itself doesn't use
additionalProperties = false. This allows extending the schemas easily, but
is sadly a bit error-prone.
Sadly, since this issue effectively disabled validation of the stage options,
we also need to relax the schema a bit:
We found out that there are manifests in the wild, that use relative paths,
instead of absolute ones. Thus, this commit changes the validation regex to
allow relative paths. However, this now emits a warning and it's strongly
discouraged. The associated stage test was modified to accommodate for this.
Co-authored-by: Tomáš Hozza <thozza@redhat.com>
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This example shows how to build a qcow2 very similar to the one
delivered by Fedora CoreOS. It uses an input container that has
the Fedora CoreOS OSTree already baked into it, which means that
the OSTree isn't built using this manifest, but taken as an input
from a remote registry.
This drains some of the logic out of `main()` into a
`ostree_commit_deploy()` function. Doing this will make it easier
to diff this stage with the recently added `ostree.deploy.container`
stage.
This commit also changes the `ref` in the schema to be optional,
which is a fixup for 3cc733d. We need to make the ref optional because
the ref could come from the user in the toplevel schema or it could
come from input commit in the schema.
This will allow a user to specify an input directly to the deploy
stage rather than requiring a ostree.pull stage to be called first.
Adding inputs will also be useful when we soon add support for
deploying from a container rather than just deploying from an existing
ostree commit in a repo.
This should just defer to rpm-ostree.
xref https://github.com/coreos/rpm-ostree/issues/4530
(If someone cares about reproducibility here, they can specify it;
alternatively and more reliably, they can create builder container
images and pin to those)
Osbuild doesn't support creating btrfs over multiple devices, thus it should
be fine to have only single and dup in the schema (other options are for raid)
So we have a quick reference how to work with btrfs-based images.
Co-authored-by: Christian Kellner <christian@kellner.me>
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
rpm-ostree 2023.2 dropped the `rpm-ostree container-encapsulate` entrypoint.
Instead, we have to use `rpm-ostree compose container-encapsulate`.
Adjust the code that it selects the correct entrypoint based on the rpm-ostree
version.
Since the new stage now requires python-yaml, add it to the buildroot and
regenerate all manifests.
This commit changes these manifests to use the new fedora-vars.ipp and
fedora-build-v2.ipp infrastructure to remove all hardcoded Fedora versions.
Note that this is currently limited only to stage tests that already use v2
manifests. v1 manifests will come later.
Notes:
The buildroot needs additional packages: zstd and openscap-utils. Thus,
all manifests had to be regenerated.
GPG keys were added where missing.
The oscap.remediation stage now creates a bunch of files with timestamps in
their names under /var/lib/authselect/backups. Thus, the newly introduced
`added_directories` directive is used to handle them.
I reviewed all changes in `diff.json` files, and they all seem sane given
that we jumped 4 releases forward.
This commit changes this manifest to use the new fedora-vars.ipp and
fedora-build-v2.ipp infrastructure to remove all hardcoded Fedora versions.
We are also able to remove the container manifests from the Makefile,
because they are no longer depending on the old f34-build-v2.json.
This commit changes this manifest to use the new fedora-vars.ipp and
fedora-build-v2.ipp infrastructure to remove all hardcoded Fedora versions.
An auto-generated ostree ref and isolabel was added to fedora-vars.
smc-meera-fonts was retired, so this commit changes it to rit-meera-new-fonts.
See
a8fe0d2620
icfg and reiserfs-utils are gone too, and they don't seem to be neccessary for
the image, so they were removed as well. Please correct me, if I am wrong.
What? I can just edit variables in one files and all(*) manifests get updated
content? That's impressive.
(*) We will be able to do all once we migrate all to the new format. For now,
the usual disclaimer applies:
This change is applied only to manifests based on fedora-build-v2 for now.
module_platform_id has a format of `platform:f34`. I have no idea why just
`f34` is used. Let's fix it.
This change is applied only to manifests based on fedora-build-v2 for now.
They are the same everywhere, we can just factor them out and save some bytes.
This change is applied only to manifests based on fedora-build-v2 for now.
Defining variables in the build pipeline is potentially dangerous, because
it can lead to the buildroot using a different package set than the other
pipelines.
Thus, this commit removes the variables from the build manifest. Since now on,
the variables must be defined before the build manifest is included.
Since the build manifest is no longer buildable on its own, let's remove it
from mpp.yaml to ipp.yaml. This is a convention set by the automotive team:
ipp manifests are not meant to be directly buildable, they are only useful
for embedding.
This is the second step of the conversion. All mpp.yaml json files were loaded
and dumped again with pyyaml. It was tweaked to keep the order of keys and to
save multi-line strings in the "flow" style. This was done, so the GPG keys
are kept on one line. Otherwise, they take up too much visual space.
There is no functional change in this commit.
osbuild-mpp supports yaml files. The advantage of yaml is that it's less
verbose and allows comments. This way, we can start documenting all the
test manifests in this repository.
This is the first step: This commit just renames the files, so we keep the
history intact. Remember: YAML is a super-set(*) of JSON, so this is fine.
There is no functional change in this commit.
(*) There are some caveats, but we don't need to care in this case.
Add a new stage to generate an OpenSCAP tailoring file. The stage
overrides a base OpenSCAP profile by enabling and disabling user
selected rules and creates a new profile name which can be used for
OpenSCAP scanning and remediation.
This is a straightforward port of the UKI from Fedora to CentOS Stream.
Changes:
- Packages that does not exist in CS9 were removed:
- shim-ia32
- grub2-efi-ia32-cdboot
- btrfs-progs
- Squashfs compression was changed from lz4 to gzip, because lz4 for squashfs
isn't enabled in RHEL 9 kernel
Include the new journald config stage to configure journald to
persist the journal. This is needed since we don't create the
`/var/log/journal` directory that journald uses to switch the
default to persistent storage. But instead of creating that
directory, we explicitly configure journald via the new stage.
This is also what Fedora CoreOS does.
A recent commit (8a7b6d3) fixed the ostree config stage and thus
we actually properly set the readonly flag for the deployment.
This broke the image since we did not specify the `rw` kernel flag
and as a consequence the ostree mounting code in the initrd broke.
Create a squashfs image from the root file system and append it
to the existing initram fs. Passing `root=live:/rootfs.img`
is enough to use the existing dmsquash machiner in dracut.
