this should allow to release the global state lock while doing resealing/sealing proper as those are slow operations in fact
* boot: use loadModeenv a bit more consistently and some XXXs
* boot: take a lock around read modeenv/modify(/reaseal) etc
* boot: do not seal without the modeenv associated lock
* boot: do not reseal without the modeenv associated lock
* boot,o/devicestate: introduce Unlocker to unlock global state
have boot.DeviceChange make use of it for a start
* boot: explain a bit more modeenvMu
* overlord: introduce state.Unlocker convenience method
* boot: check that the lock is taken also in bootStateUpdate20.commit
* many: introduce IsUndo flag in LinkContext
Some times LinkSnap is called in an undo task when we want to revert
to a previous snap revision. Introduce a flag to make LinkSnap and
boot code aware of when this happen, as some of the logic for snap
installations should not be applied when doing a revert. Specifically,
avoid the "try" logic that applies to kernels and bases: we are
reverting to a known snap that is expected to work, and making the
current snap the fallback provokes failures as we are removing it (and
also probably we are removing it because it has failed).
* tests: check that kernel with failing post-refresh is reverted
Check that a kernel with failing post-refresh hook is reverted
properly. In this case a second reboot to go back to the previous
kernel is needed.
* tests: check that base with failing post-refresh is reverted
Check that a base with failing post-refresh hook is reverted
properly. In this case a second reboot to go back to the previous
base is needed.
* boot,overlord: replace isUndo flags with NextBootContext
Replace isUndo flags with the NextBootContext struct, so we have
further information in the type and we can add flags in the future.
* boot: some style changes as suggested by review
* overlord: SetNextBoot call in maybeUndoRemodelBootChanges as undo type
* boot: add tests for the IsUndoingInstall true case
* overlord: fix remodel test for undos
* boot,overlord: implement the undo install for core16/18
* tests: added method to repack kernel snap also for core16/18
* tests: run revert after boot tests for UC16/18 too
* tests/nested/core/base-revert-after-boot: fix var usage
* tests: consider right channel/snap for uc16 in revert tests
* boot: minor stylistic changes
* boot: add tests for the undoing install case for core16/18
* boot,overlord: rename IsUndoingInstall to BootWithoutTry
* boot: use constant instead of literal for status
Now SetNextBoot() will return a RebootInfo struct that will include a
bootloader.RebootBootloader interface, instead of just a bool
indicating if rebooting is required. This allows to obtain additional
information from the bootloader while rebooting.
Currently there is no need for coreKernel{} to keep track of the device. Getting
hold of bootloader options is sufficient to set up the right bootloader
implementation.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
This allows us to ask the device if we are on UC20 essentially, and figure out
what options we should use when searching for a bootloader to extract/remove
kernel assets from.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
now bootState.revisions fails if the current snap revision is not
set, that's the behavior GetCurrentBoot needs but this required
some tweaks to InUse again
added some TODOs for later consideration as well
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
Thanks @zyga and @pedronis for the reviews.
This makes things a lot tidier: instead of interfaces
`boot.BootParticipant` and `boot.Kernel`, and functions `boot.Lookup()`
and `boot.LookupKernel()`, we now have interfaces `boot.BootParticipant`
and `boot.BootKernel`, and `boot.Participant()` and `boot.Kernel()`.
This change simplifies using the recently introduced
boot.BootParticipant and boot.Kernel interfaces. Two changes:
1. `boot.Lookup` is split into `boot.Lookup` and `boot.LookupKernel`,
and a `boot.Kernel` is no longer a `boot.BootParticipant`, and
2. `boot.Lookup` (and `LookupKernel`) return a single element that's
always non-nil but might be a trivial implementation of the
interface. A caller can always call the associated methods, and
they'll do nothing when not 'applicable'. Optionally the caller
can check whether it's the trivial implementation by using the new
`IsTrivial()` helper.
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.
