The import of `dnf-json` came from `osbuild-composer`, as we sadly
have/had multiple copies this wasn't the *right* version as it was
lacking previous work to disable weak dependencies.
In the case we are not using a buildroot (i.e. we are using
the host as the buildroot) let's also mount in /etc/containers
into the environment. There are sometimes where software running
from /usr can't operate without configuration in /etc and this
will allow it to work.
An example of software hitting this problem is skopeo. With a
simple config like:
```
version: '2'
mpp-vars:
release: 38
pipelines:
- name: skopeo-tree
# build: name:build
source-epoch: 1659397331
stages:
- type: org.osbuild.skopeo
inputs:
images:
type: org.osbuild.containers
origin: org.osbuild.source
mpp-resolve-images:
images:
- source: quay.io/fedora/fedora-coreos
tag: stable
name: localhost/fcos
options:
destination:
type: containers-storage
storage-path: /usr/share/containers/storage
```
We end up hitting an error like this:
```
time="2023-10-24T18:27:14Z" level=fatal msg="Error loading trust policy: open /etc/containers/policy.json: no such file or directory"
Traceback (most recent call last):
File "/run/osbuild/bin/org.osbuild.skopeo", line 90, in <module>
r = main(args["inputs"], args["tree"], args["options"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/run/osbuild/bin/org.osbuild.skopeo", line 73, in main
subprocess.run(["skopeo", "copy", image_source, dest], check=True)
File "/usr/lib64/python3.11/subprocess.py", line 571, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['skopeo', 'copy', 'dir:/tmp/tmp5_qcng99/image', 'containers-storage:[overlay@/run/osbuild/tree/usr/share/containers/storage+/run/containers/storage]localhost/fcos']' returned non-zero exit status 1.
```
This PR adds in a mount for /etc/containers from the host so that
/etc/containers/policy.json can be accessed.
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 stage is similar to ostree.deploy, but deploys from a container
image rather than from an OSTree commit by using the `ostree container
image deploy` command. An example stage definition could look like:
```
- type: org.osbuild.ostree.deploy.container
options:
osname: fedora-coreos
target_imgref: ostree-remote-registry:fedora:quay.io/fedora/fedora-coreos:stable
mounts:
- /boot
- /boot/efi
kernel_opts:
- rw
- console=tty0
- console=ttyS0
- ignition.platform.id=qemu
- '$ignition_firstboot'
inputs:
images:
type: org.osbuild.containers
origin: org.osbuild.source
mpp-resolve-images:
images:
- source: quay.io/fedora/fedora-coreos
tag: stable
```
Co-authored-by: Dusty Mabe <dusty@dustymabe.com>
The test for this stage is failing because etc/shadow changes content
depending on the date that it runs on (due to the "date of last password
change" field). This causes the checksums to not be constant for our
tests and depends on the date.
This commit removes the checksums for etc/shadow from the test so that
they are not checked as part of the test. This worksaround the test
failure issue for now until a solution to the dynamic contents is
determined.
Signed-off-by: Michael Ho <michael.ho@ieee.org>
Import the `dnf-json` Python script that is included in the "images" and
"osbuild-composer" repository into "osbuild".
`dnf-json` provides dependency solving capabilities by taking in some
JSON and then outputting the package set that JSON resolves to. Since it
is a Python script it moves into a subpackage of `osbuild`.
The script is renamed to `osbuild-depsolve-dnf`.
This adds an early return to the `_process_ostree_commits` function to
prevent an empty ostree commit object from being created in the deploy
stage which causes violations to the deploy stage input schema.
Added three users to the test to test all combinations of ssh key
definitions:
- a user called `onekey` that has a single key defined in the `key`
option.
- a user called `multikey` that has a multiple keys defined in the
`keys` array.
- a user called `bothy` that defines both a single key in the `key`
option and two other keys in the `keys` array.
Add a new attribute, "keys", to allow specifying multiple public SSH
keys to install to a users authorized_keys file.
This maintains backwards compatibility with the existing "key" attribute
that can only specify a single SSH key to install into the file (without
using some newline hacks).
Signed-off-by: Michael Ho <michael.ho@ieee.org>
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.
I've been informed that this stage is old and shouldn't be used for
newly created manifests. Let's add a comment to the top for future
explorers of this code base.
Some platforms like the TI AM62 require a particular FAT geometry for
their CPU to read the file system (and thus the bootloader). Failing
that the CPU will simply not boot and keep looking for a bootloader.
Let's add some options to enforce a particular filesystem geometry
through the -g option of mkfs.fat.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The current options building code for mkfs.fat prevents to have multiple
options at a time since it will assign the opts list to either the label
or fatsize options.
If both are set, only the last one, fatsize, will be set.
Use the occasion to rewrite the code a bit and limit the number of
lists concatenation.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
This will hoist even more code into util out of the skopeo stage.
Now a caller can call:
with containers.container_source(image) as (image_name, image_source):
print(f"{image_name}, {image_source}")
to process containers inputs.
This hoists container handling code from the skopeo stage into
util/containers. It is prep for adding another stage that accepts
containers as an input. The code is common so we should share it
amongst all stages that use containers as input.
The file `./samples/base-qcow2.json` used in the osbuild.1.rst
man-page does no longer exists. It was removed in e92b409 and
`samples` is now a symlink into the test data. The closest in
the test data to the original `base-qcow2.json` seems to be
the `fedora-boot.json` so this is now used in the examples
section.
This removes the references to `./samples/base-rpm-qcow2.json`
which was remove in fe95d93. Here `fedora-boot.json` is also
used.
For Fedora CoreOS we don't actually have any root= kernel command
line option in our baked images. We have services that rely on this
and set up sysroot on first boot. The code in this stage doesn't
require for this option to have been provided and actually gracefully
handles when it's not provided. Let's just change the schema to also
not require it.
autosd is a CentOS Stream 9 derivate. User reported:
"ValueError: No suitable runner for org.osbuild.autosd"
in Automotive SIG community Matrix. We are going through some name
changes at the moment.
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)
A simple test to make sure that our btrfs stages work.
Updating the testing container is needed, because the old version
didn't have btrfs-progs in it.
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)
