We will need to add Model to Device for UC20 cases, prepare for that
by forcing MockUC20Device to use one and produce output consistent
with it.
Make also the behavior of MockDevice a bit more consistent/realistic
though it has limited use for UC20, it allowed for mode != "run"
with HasModeenv false for example.
This is needed because the uc18/uc16 bootloader implementations do not actually
do this, and instead snapd needs to reset the value.
Also modify the bootenv bootloader logic simulation to not clean this anymore,
just as the real bootloaders do.
This all requires some slight changes to the test logic, which since they are
checking the BootVars map directly will see some additional empty keys in the
map as markSuccessful will now write those empty keys. Eventually we should port
these tests to use GetBootVars and not use the map directly since empty
string keys show up the same as missing keys with GetBootVars and that would
have prevented needing to change these tests at all.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This internally uses Bootenv16, with snap_mode usage replaced with kernel_status
which is what we have for UC20.
Also fix doc-comment on RunBootenv20.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
In a future refactor of the boot tests, we will always need to write out a new
modeenv in the tests and never just read it, so we don't need this mocking
utility anymore.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This is more consistent and means the same thing everywhere else, except for one
test helper which is also updated here to now mean the same thing.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This makes future tests simpler, and since it's all in memory is simpler than
writing out the files to the filesystem for each test, since restoring it is
just defer'ing the returned function.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This will be used by bootStateFor in determining if a given device is a UC20
device and thus needs a different bootState implementation.
Adjust some tests to ensure that we have a modeenv when expected and don't when
expected.
This also requires refactoring the MockDevice in boottest to be slightly more
complicated to have devices that are in run mode, but are not uc20.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
instead of passing model and/or a classic flag to them
and adding operating mode now as well, pass a new interface
boot.Device that is implemented by DeviceContext
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.
This makes it so that only tests that care about the boot mechanics
need to care about the details of it.
These tests might be better off be split and part of them moved into
boot, as there's little reason for them to be where they are caring
for the level they have (e.g. devicemanager shouldn't need to care
about the vagaries of boot rollback, probably).
But that's work for another PR.
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).
