Extend the stage to allow explicitly configuring more grub2 default
config options. Preserve the defaults for options which were previously
hard-coded.
Extend the stage unit test to verify setting of the new grub2 default
config options.
Related to https://issues.redhat.com/browse/RHEL-19583
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Extend the stage to allow explicitly configuring more grub2 default
config options. Preserve the defaults for options which were previously
hard-coded.
Extend the stage unit test to verify setting of the new grub2 default
config options.
Related to https://issues.redhat.com/browse/RHEL-19583
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Small unit test for the new `org.systemd.unit.create` stage. It
will do basic schema validation checks and ensures that a simple
service definition is correctly translated to a systemd unit.
The bootc.install-to-filesystem code needs to run against the
root directory of a mounted tree, i.e. with /boot, /boot/efi
mounted. So change the code so that the target dir is the
the "mounts" paths. This is similar to how bootupd works and
the caller need to arrange the right mount setup there.
Add systemd unit files in osbuild stage
This stage creates systemd unit file in `/usr/lib/systemd/system/`.
The stage accepts filename which must end with `.service`.Section
`Unit` , `Service` , `Install` accepts various parameters as per
the systemd documentaion.`systemd-analyze verify` is be performed
after the .service file is created to check for potential errors.
Signed-off-by: Sayan Paul <paul.sayan@gmail.com>
This commit adds a test that ensures that the output of
podman mount is part of the error message. While writing
the test I also tweaked the code slightly so that we only
try to `podman umount` if we managed to successfully mount.
This commit adds example manifests for a bootc.install-to-filesystem
system. It does not do more with them because running a full test
requires a working podman which is difficult to use inside our
GH runners that are already running inside docker.
This adds a `default: true` option for all cases where OSTree
information is specified in schemas and allows for the information
to be picked up from the filesystem.
This is a safe operation because when building disk images there is
no known case where having two deployments makes sense. In the case
there ever were a case then the osname, ref, and serial options still
exist and can be used.
Co-authored-by: Luke Yang <luyang@redhat.com>
Co-authored-by: Michael Vogt <michael.vogt@gmail.com>
It seems like an artifical limitation to prevent copying from a mount
or from one location in the tree to another. It just so happens we need
this functionality when building CoreOS images because we want to take
a file embedded in the OSTree at a location and copy it to another
location in the tree. The particular example here is we want to copy
/usr/share/coreos-assembler/platforms.json -> /boot/coreos/platforms.json
See https://github.com/coreos/coreos-assembler/pull/3709
Allowing to copy from/to the tree we can now do something like:
```
- type: org.osbuild.copy
options:
paths:
- from: tree:///usr/share/coreos-assembler/platforms.json
to: tree:///boot/coreos/platforms.json
mounts:
- name: ostree.deployment
type: org.osbuild.ostree.deployment
options:
deployment:
ref: ostree/1/1/0
osname:
fedora-coreos
```
In some cases it could useful to add additional kernel options without
modifying BLS config, so any subsequent call to `zipl` would ignore them.
We are going to use this to append `ignition.firstboot` to kernel cmdline
for CoreOS on s390x.
This stage was failing for me in bib, with this change I now
get more useful information from podman's stderr, e.g.:
```
RuntimeError: Failed to mount image (125): time="2024-02-06T14:23:06Z" level=error msg="Unmounting /var/lib/containers/storage/overlay/06456126e7c06cf1b21de024e08e64eddead2b8d03779be213e63aeeea9dec94/merged: invalid argument"
Error: creating overlay mount (...snip...)
fuse: device not found, try 'modprobe fuse' first
fuse-overlayfs: cannot mount: No such file or directory
```
Runs bootupctl generate-update-metadata in the tree to transform
/usr/lib/ostree-boot into a bootupd-compatible update payload.
This stage should be run on the sysroot of an ostree deployment or
ostree-converted tree.
We only support `gpt` here so it would seem this option doesn't
make much sense to add, but it will make it so that the mpp-define-images
from osbuild-mpp can be passed in to `org.osbuild.sgdisk` just as it
can be passed in today to `org.osbuild.sfdisk`.
Partitions by default are indexed starting at 1, but in
some cases, such as CoreOS for IBM Z, it may be usefull
to set the 'partnum' for GPT disks explicitly, without
creating dummy partitions.
Now user can define an image:
```
mpp-define-images:
- id: image
size: 10737418240
table:
uuid: 00000000-0000-4000-a000-000000000001
label: gpt
partitions:
- name: boot
type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
partnum: 3
size: 786432
- name: root
type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
partnum: 4
size: 4194304
```
So target disk would look like:
```
Disklabel type: gpt
Disk identifier: 00000000-0000-4000-A000-000000000001
Device Start End Sectors Size Type
/dev/loop0p3 2048 788479 786432 384M Linux filesystem
/dev/loop0p4 788480 4982783 4194304 2G Linux filesystem
```
This patch updates the osbuild-mpp tool and the sgdisk and sfdisk
stages to support this.
Co-authored-by: Dusty Mabe <dusty@dustymabe.com>
This adds an optional `paths` option to the tar stage. If specified, the
paths will be included in the tarball in order.
The OVA image needs to have its contents in a specific order in the
archive.
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.
