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.
Don't print systemd-nspawn's messages about starting and stopping
containers.
Also supress a ldconfig warning and only show output from
systemd-sysusers when it fails.
