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>
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 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>
All stages must be able to handle an input_dir argument, as we now
either pass it to all or none for agiven run. Simply set it to
'None' if it is not provided.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Stages should be as stateless as possible. Don't provide an easy way out
of that.
Only the dnf stage used stage to save the dnf cache. That's only useful
during development and can be solved by pointing to a local repo mirror.
Introduce `run-stage` script, which sets up the build environment before
running the stage. Run `ldconfig`, `systemd-sysusers`, and
`systemd-tmpfiles` in it.
Use systemd-nspawn's "volatile" mode, which creates a tmpfs for the root
directory. This ensures that we're not accidentally using configuration
from the host.
The only remaining hole is `/etc/pki`.
Anaconda cannot run without its configuation in `/etc`. Recreate the
defaults.
Rather than treating the dnf-cache specially, give each stage its
own state directory that they can reuse. This should obviously be
used with care by the stages in order to make the builds
reproducible.
Some stages will be chrooting into the target to run things there,
and they will require the standard API VFS to be mounted. Some
tools do that themselves, other do not. In all cases, we would like
to discourage running things in the target tree.
For these reasons do not pre-mount the API VFS, but require the
stages who need it to do the mounting themselves. This is a partial
revert of f6023ed78b.
