This is not used anywhere anymore, so let's just drop it. If we need it again,
we can bring it back.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
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>
Address TODO added during UC20 development and use a ForGadget helper when
installing boot configs of a bootloader.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@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>
This commit adds a new InstallBootCofig to the bootloader
interface. The bootloaders use the generic uc16 implementation
currently so nothing changes. But this will make it possible
to have different behavior for the install of the bootconfig
for uc20 where we will need to install a recovery boot config
and also a "run" mode boot config.
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
Currently the logic of boot has a lot of per-snap-type cheks in the
exported functions. Going forwards into core20 we know these checks
are going to get more involved, so now is a good time to switch things
around so that different implementations exist for each of the
situations, and thus the checks can be done while looking up which
implementation to use, instead of in each of the functions.
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).
Different bootloaders might have different requirements about boot
asset extraction. Cleaner way is to move this implementation to each
bootloader implementation
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>
