to achieve this change the signature of MakeBootableImage (also drop
now unused argument)
setImageBootFlags needed adjustments and also the tests using it
Split out bits that make the recovery system bootable. Those will be used
independently when creating a recovery system and setting it up for boot.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
When setting up the run system, set the kernel command line arguments provided
by the gadget.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
When preparing an image, make sure that the recovery system contains the kernel
command line arguments requested by the gadget.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Split makeBootable20 into two parts, one MakeRunnableSystem and
MakeBootableImage, with the former being exclusively for image-prepare time ops,
and the latter being for UC20 install mode preparing an active run system.
Additionally, for MakeRunnableSystem, remove out the final bit which sets the
boot variables and officially marks the point at which the system is ready to be
rebooted into the run mode. This will allow us to refactor the install mode
changes more easily in a future commit, but for now we get the same behavior
with EnsureNextBootToRunMode() in the install mode setup-run-system task.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
We need this to be exported to be able to serialize a trusted asset observer
across multiple tasks during UC20 install mode. The only state that is not
currently observable from filesystem state are the keys and the boot asset maps
for tracked assets here. The keys can easily be saved in state.json to
serialize, but the boot asset map needs to be exported to be able to serialize
it in the state.json across tasks.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* devicestate: implement boot.HasFDESetupHook
This commit adds support for boot.HasFDESetupHook and matching
tests.
* devicestate: move hasFDESetupHook setup into delayedCrossMgrInit()
* boot,devicestate: use deviceCtx to get fde-setup hook data
* devicestate: improve TestHasFdeSetupHook test
* devicestate: tweak TestHasFdeSetupHook further
* boot,devicestate: remove "bootWith" from SealKeyToModeenv() again
* boot: tweak error message
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* o/devicestate: tweak error messages and comments
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Co-authored-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* boot: add scaffolding for "fde-setup" hook support for sealing
Add intial support for sealKeyToModeenv() to support running
a "fde-setup" hook instead of using the build-in secboot
implementation for key sealing.
This is broken out of the larger
https://github.com/mvo5/snappy/tree/fdehook-skeleton-2
branch.
* boot: tweak naming/coments for HasFDESetupHook/RunFDESetupHook
* boot: collect the fde hook functions into a single var stanza
Co-authored-by: Samuele Pedroni <pedronis@lucediurna.net>
This is the first step to doing away with the current default of
snapd_recovery_mode being unset implying "install". We need prepare-image (and
thus also ubuntu-image) to start writing "snapd_recovery_mode=install".
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
