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>
6ae19579c1