Now we have a specific method on the Bootloader interface which tells Find()
whether the specific bootloader is actually present on the current system. This
will simplify future bootloader implementations to be able to return errors when
identifying if a bootloader is present on the system is more complicated a
question than just if the config file for that bootloader exists.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
The bootloader.Find() expects bootloader configuration to be present in the root
directory. However, when we are installing a run mode system, the bootloader
config is not present until after InstallBootConfig() gets called, which happens
only after the filesystem has been created and populated. However, when using
the ContentObserver to track trusted assets, we must know what the bootloader
is.
Add a helper for creating a bootloader based on what is carried by the gadget.
Move the basic checks for config file existence to Find().
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
We want to eventually expand Container to take an options struct to Install()
for example, which means that the squashfs and snapdir implementations need to
import "snap" pkg to understand that option struct, but this would lead to an
import cycle since the "snap" pkg also imports squashfs and snapdir packages
directly.
The solution is to make "snap" pkg not import the squashfs and snapdir packages
and instead have Open and the formats listing live in another package so that
the formats will always get loaded by just using Open() directly. The new
snapfile package is where Open lives and it imports "snap", the squashfs
and snapdir packages without import cycles.
This requires numerous changes across the codebase to use snapfile.Open now.
the only option for now is for knowing whether
ths bootloader is being used in prepare-image
this should help cleaning up the LittleKernel work
this is only an intermediate step toward refactoring image
vs boot/bootloader interaction
The Bootloader.Dir() method is no longer needed and can be removed.
It used to be used to extract kernel assets but that is now part
of the Bootloader interface so expect for test code nothing is
using "Dir()" anymore. The extraction of boot assets is now done
via the Bootloader interface directly.
Note that Dir() also does not make sense for bootloaders that work
inside partitions (like littleKernel).
After moving ExtractKernelAssets and RemoveKernelAssets implementation to bootloader's
implementation, tests needs to be updated.
Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>
The 'partition' package is actually about bootloaders, so 'bootloader' name
seems more fitting.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>