This new manifests creates an boot iso which contains an ostree
commit that is build in the same manifest. The boot iso can then
be installed via the ISO.
New stage that uses the implantisomd5(1) to implant MD5 checksums
into an ISO. This is then used by a dracut module in the installer
ISO to check the installation medium.
Add a new stage that uses the `xorrisofs`(1) command line utility
to assemble a. The iso can be made bootable by specifying a
combination of the `boot` and `efi` options.
Add a new stage that prepares a bootable file system tree suitable
for writing to an ISO file system. It currently only supports
EFI and PC-BIOS boot. It takes a tree input which will be wrapped
into a ext4 file-system wrapped into a squashfs image.
Add a new stage that uses the recently added lorax template
helpers to execute such a template. The template itself will
be search in the build root, but the command of the script
will operate on the tree.
A new module that can parse and execute Lorax script templates,
which are mako template based files that support a limited set
of commands, like "install", "remove" and such.
The module provides helper functions to parse such templates
and execute them by providing a re-implementation of a subset
of the commands. All commands needed for running the post
installationtemplates were implemented.
Add a stage to create a buildstamp file, which is required by
anaconda to properly function, since it configures varies
aspects of the installation target (product, build arch, ...).
Add a stage to configure anaconda. For now only the enabled
kickstart modules can be configured. This is done by dropping
a file "90-osbuild.conf" in `/etc/anaconda/conf.d`.
There was a bug in mke2fs (fixed in versionv 1.45.7, with commit
6fa8edd0) where mkfs.ext4 would fail because the default config,
created on the fly, would contain a syntax error. The program
would abort with:
Syntax error in mke2fs config file (<default>, line #22)
Unknown code prof 17
To avoid this error, we try to bind mount the config from the build
root.
Since pipelines can now be uniquely addressed via their names,
add the ability to checkpoint via the pipeline name. This will
effectively checkpoint the last stage of a pipeline.
For format v1 manifests, the build pipeline is called "build",
the main pipeline is called "tree" and the pipeline for the
assembler is called "assembler".
This is to test the functionality of the new `saved_entry` grub2
config file. Ideally an integration test would install a new non-
default kernel and check that it does not get selected. Something
for the future.
The current grub configuration has no logic to select the default
boot entry, which means the next boot entry is chosen by grub2
by the sort order of available entries. This will break tooling
like grub2-set-default and grub2-reboot that set on a specific
variable `saved_entry` in the grub environment file `grubenv` to
to point to the select boot entry.
Change our grub configuration file to use that `saved_entry` var
to select the next boot entry to unbreak the tooling.
In addition to the aforementioned tools, the saved_entry is also
updated by the kernel install scripts when new kernel is installed,
but only if the newly installed kernel is the selected default.
Thus not respecting the `saved_entry` variable might cause a bug
where a newly installed non-default kernel gets selected by grub2.
Use the new immutable image infrastructure from `osbuild/containers`.
While at it, also switch over to the new github-actions helper, now that
we no longer run `systemd-nspawn` in our tests.
The old image was renamed from `ghci-osbuild` to `osbuild-ci` to avoid
accidentally replacing old images. The new infrastructure uses immutable
images, so downstream will no longer get automatic updates, unless the
`latest` tags are used.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
Although MPP supported having multiple repo entries for each
depsolve block, in reality that didn't actually work because
the same (global) baseurl was used for all packages.
Now the basurl can still be (otionally) specified globally,
but also overridden by the repo block and the package paths
will be relative to that.
In addition to the required base layer, provided via the the input
of the same name, the oci-archive stage now accepts up to nine
additional layers that get added on top of each other, sorted in
ascending order, i.e. `layer.1` to `layer.9`.
Adapt the `fedora-ostree-container` example manifest so that the
ostree commit is now in a separate layer, which makes it possible
to share the base layer between different commits container.
Add a new basic test for the dracut stage. It uses a osbuild
pipeline to build an initrd and inspects it via the initrd.py
module. The content is compared to a reference located in the
same directory as the pipeline (test/data/stages/dracut/).
Add a new module that contains a utilities to inspect an initrd.
It contains a `Initrd` class that loads a given initrd and can
then be used get the list of files via Initrd.filelist, the dracut
modules via `Initrd.modules` and the kernel modules via the
`Initrd.kmods` properties. Another top level function `read_initrd`
returns a dict that contains the name of the initrd as key and as
value another dictionary with `modules`, `kmods` as well as the
`compression` & `early_cpio` metadata.
The initrd.py can also use as a script that will print the dict
from `read_initrd` as JSON.
The implementation is a heavily based on dracut's `lsinitrd` bash
script and additionally contains a python port of the skipcpio.c
utility.
Should enable greater flexibility of how the initial ram disk is
created. Most importantly it runs dracut by default in no-host-
mode, which is the mode where dracut only includes the drivers
its needs for the currently running system. This mode obviously
does not make much sense in the installer.
The naming of the options follows the dracut nomenclature.
If the run of dracut has been disabled via installing a link to
/dev/null in /etc/kernel/install.d and after the installation of
the packages the /etc/kernel directory is not owned by any newly
installed packages, remove it again.
Add the ability to prevent `dracut` from running via the post
install scripts. This is done by installing symlinks named
like the dracut scripts in `/usr/lib/kernel/install.d/` in
`/etc/kernel/install.d`. They symlinks point to `/dev/null`
and since the ones in `/etc` takes precedent over the system
ones they effectively disable dracut from running.
After the run is completed the symlinks are removed and the
original files thus unmasked.
Change the test manifests that use containers to not include
docs when installing. Also don't install docs in the build root
for those manifests. Since the fedora-ostree-container.mpp is
being built in CI, this also tests that the new option.
The `org.osbuild.files` source provides files, but might in the
future not be the only one that does. Therefore rename it to
match the internal tool that is being used to fetch the files.
This is done for most other osbuild modules that target tools.
The format v1 loader is adapted to make this change transparent
for users of the v1 format, so we are backwards compatible.
Change the MPP depsolve preprocessor so that for format v2 based
manifest `org.osbuild.curl` source is used. Also rename the
corresponding source test. Adapt the format v2 mod test to use
the curl source.
Instead of supplying the full cache dir, i.e. the directory in
the store where the source will place the fetched resources, to
the source, only supply the root folder of the cache and let
the source itself create the desired sub-directory. This allows
the source to determine what type of resource it provides. This
makes the final directory independent of the name of the source:
a `org.osbuild.curl` source can place file-like resource in the
`org.osbuild.files` sub-directory. Then the `org.osbuild.files`
input can be used to get those from the cache directory.
Previously, we had a webhook relay. It received a notification from Github
and sent it to AWS SQS. Now, the webhook is dead. The new method (already used
in osbuild-composer and image-builder) is to send the notification directly
from a github action to AWS SQS.
Add a v2 manifest to builds an ostree commit, then builds a small
container with a webserver and puts that commit into it.
Start a new test suit where this manifest is built and then checked
that the artifact exists. In the future the artifact should also be
inspected and run by a container engine and the commit be pulled
via ostree.
Add a basic check to verify that loading and then describing the
pipeline results in the same description that was put in. This
test is esp. valuable because it checks the runner mapping and
name, id mappings.
Add a new test to check that validation works for the basic test
pipeline. This needs to be extended in the future to check that
invalid data is being caught properly, but it is a start.
Add a simple noop pipeline, with a noop stage and a noop input,
which all in all does nothing much; but it will validate, load
exectue the pipeline, stage and inputs. So maybe not really
"nothing" in the strictest sense.
In format version 2, the source specific keys for the sources,
here "urls", is replaced by a generic `items` key, common to
all sources. Express that in the schema.
Port the `org.osbuild.ostree.commit` assembler to a new assembler
like stage. The notable differences are: the fs tree preparation
now happens in the `ostree.preptree` stage and there is no option
to create a tarball, since that should be handled by a tar stage.
This new stage is a combination of the existing `rpm-ostree` stage
and the old `ostree.commit` assembler. It first does prepare a new
OSTree compliant root fs (previously done in `ostree.commit`) and
then uses `rpm-ostree tree postprocess` to perform various post-
processing on the tree to make it fully OSTree compliant.
