configparser writes strings with quotes and lists with enclosing
brackets, both of which may not appear in dnf.conf.
dnf.conf(5) defines the format loosely.
This removes the possibility of passing in arbitrary input data. We
now restrict ourselves to explicitly specified files/directories or
a base tree given by its pipeline id.
This drops the tar/tree stages/assemblers, as the tree/untree ones
are implicit in osbuild, and if we wish to also support compressed
trees, then we should add that to osbuild core as an option.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This allows one pipline to build on top of another. When the pipeline
id of one pipeline is specified in another, the tree is initialized
with the output of the given pipeline.
The caller must ensure that the base pipeline has alreday been run,
and its content is in the content-store.
This renders the io.weldr.untree stage and the --input argument both
redundant.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Whenever an assembler is not specified, the output tree is instead
saved to the content store, in a directory named after the pipeline
id.
This should render the io.weldr.tree assembler redundant.
In order to build the samples as before, specify the content store
as the input directory to build any pipeline that uses the
io.weldr.untree stage.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This uniquely identifies a pipeline based on its content. Pipelines
are considered equal modulo whitespace and the order of object
elements.
The intention is that two runs of a pipeline with the same id
generates functionaly equivalent ids. It is up to the writers
of stages and pipelines to ensure this property holds.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Afetr discussions with Javier Martinez Canillas and Alberto Ruiz
from the grub team, it was clear that we want move to a static
configuration shipped in the grub rpm in the future. For now,
we use our own, but the aim is to use the same as upstream.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The boot loader snippets were not being generated on f29, we may want
to revisit that, but for now let's work against f30.
Signed-off-by: Tom Gundersen <teg@jklm.no>
By default the whole image file is attechd to the loopback device, but
we want to only attach a slice, namely individual partitions.
This is a noop, just adds the parameters to the helpers.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We only need the filesystem with the correct fs-UUID to chroot into,
there is no need to set up a whole partition table.
Signed-off-by: Tom Gundersen <teg@jklm.no>
These are meant to test the various assembers and stages and to show how pipelines
can be created. However, they are not meant to necessarily be the best way to create
any given image.
Note that some of the pipelines are dependent on each other.
This follows what is done for the stages. We intend to look into
making this unnecessary, but for now allow full access so we can
work on the individual assemblers.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is for the sake of debuggability, but I figure dnf is the most
complex of our tools, so instrumenting that a bit makes sense.
The defaults are "install" and "info", as before.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We wanted to force an empty output dir to avoid assembly stages using
previous output when creating their new one, and hence creating
dependencies between osbuild runs. We may still do that, but for now
let's remove the restriction as it seems rather arbitrary to protect
people from themselves to this extent.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We cannot use the tool from within the tree unless we chroot
(library versions ay be wring etc). If possible we want to
always use tools from the build image, in order to avoid forcing
the contenst of the target tree, so do that instead.
Finally, add a missing include.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We want to copy the contents of a directory to another, the correct
syntax for that is `cp -a src/. dst`. I was not aware of this beauty,
so the previous patch simulated the functionality in python code.
Signed-off-by: Tom Gundersen <teg@jklm.no>
In the simplest case we don't need to make an image, a filesystem tree
will do. Also support using such a tree as input for further pipelines
through the untree stage.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The stage populates the tree with grub2 configuration. The API and
semantics is the way we want it, but internally this is a massive
hack.
GRUB2 is only able to run grub2-mkconfig on the image it wants to
configure. The reason is that it will inspect / and /boot to detect
the existing UUIDs and filesystems to use, despite this being
information we already know. In principle, the tool does support
passing this is, but due to several bugs that functionality does
not work.
We therefore create the image we want, copy over the tree, run
grub2-mkconfig in this image, then copy it back over the tree. The
end result is that the files /etc/defaults/grub,
/boot/grub2/grub.cfg and /boot/grub2/grubev are added to the tree.
The alternative would be to do what tools typically do, and just
run grub2-mkconfig on the final image at the time it is being
assembled. We want to avoid this in order to fully split filesystem
tree generation from image assembly. This way we can better control
and verify what ends up on the filesystem which should help with
reprobucibility and reuse of filesystem trees. Above all though,
we want to make sure that we can actually place some guarantees
on what each stage of the image building process actually does,
allowing us to argue about and change it without worrying about
arbitrary fallout.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We need dynamic device node creation when we create loop devices
and their partitions. It would be possible to mknod them, but
just using the host /dev seems more straight-forward. Access to
the various nodes still needs to be granted explictly as we are
in the devices CGroup.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We are in the devices namespace, so we must explicitly grant
permission to devices and/or device classes if we are to use
them.
We rely on being able to create and access loop devices in
order to create partitions and filesystems.
/dev/loop-control allows us to create new loop devices backed by
files. The block-loop class allows access to the created block
devices to set up a partition table and the block-blkext class
allows access to the partitions to create and mount filesystems.
Signed-off-by: Tom Gundersen <teg@jklm.no>
It's not really useful because it's at the wrong place, after a stage
has torn down all mounts. It also makes the code more complex for too
little benefit.
