This commit fixes a a bug in master that will prevent
`MarkBootSuccessful` from working. The issue is that on classic+modes
the modeenv no longer contains a `base=` field but the
MarkBootSuccessful code will fail if it is missing. This results
in a system that never marks the boot as successful on classic+modes.
* boot: do not include `base=` in modeenv for classic+modes installs
This is a followup for the PR#12532. Right now the system does
put the `base` into the modeenv on `classic+modes` system. But
here there is no need to keep track of the base as it is not
used for booting, the deb based classic system is used for that.
* boot: clarify comment in makeRunnableSystem
Go 1.19 includes some changes to gofmt which intend to make lists and
heading clearer when rendered (https://go.dev/doc/go1.19). This commit
is the result of running the new gofmt and manually fixing some of it.
This was necessary because the new gofmt assumed lines beginning w/ tabs
to start lists or examples. While this is often true in our codebase,
we occasionally also use tabs to indent the lines after a TODO or FIXME
prefix or in yaml (e.g., excerpts of a snap.yaml). This meant that a lot of the
reformatted comments were broken and had to be fixed manually.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
In case a bad try kernel was in the disk (i.e. by just a simple
dangling symlink try-kernel.efi), we entered a boot loop. Avoid that.
* tests: add test that checks that there is no boot loop
when we have a dangling try-kernel.efi symlink.
* boot: return status when asking for kernel revisions
Return status when asking for kernel revisions even if there is no try
kernel. It will still be useful. Also, add some clarifying comments to
genericInitramfsSelectSnap.
* boot: clarify comments and traces
* boot: add test for bad try status with no try kernel
* cmd/snap-bootstrap: adapt error string in tests
Due to changes in bootstate.
When we were aborting a kernel installation before a reboot happened,
a proper clean-up of left-overs was not happening. To fix that, make
sure that current kernels in modeenv is always set appropriately and
also make sure that the try-kernel.efi symbolic link used by the grub
bootloader is removed.
Use accessors to access fields from LaidOutStructure.VolumeStructure,
concretely the fields that have the same name as in OnDiskStructure,
so we can transition more easily to the latter when we include it in
the LaidOutStructure struct.
* o/state: fix pendingChangeByAttr initialisation when loading state
* o/restart,o/state: introduce restart.FinishTaskWithRestart
this combines setting the status of a task being finished and requesting a
restart
it will also replace rebooting the system on classic with setting the task into
HoldStatus until a manual system restart occurs
moving the task from HoldStatus to DoneStatus is implemented with
RestartManager.StartUp logic based on extra state attributes to track reboot on
such task and its change
to avoid such pending changes to be pruned prematurely a predicate
RestartManager.PendingForSystemRestart is registered with
State.RegisterPendingChangeByAttr
* overlord: delegate from snapstate.FinishTaskWithRestart to restart
this gives us the right behavior on classic now
adjust tests to the expected behavior, fixing previous XXXs
* o/snapstate: switch around NoErrorOrHold to IsErrAndNotHold
this way fewer places need to negate it
thanks MiguelPires
* o/restart: simplify things a bit turning held-for-system-restart into just a flag
on the Change, instead of a full counter
* o/restart: try to clarify FinishTaskWithRestart behavior in comment
* o/state: do not attempt to run tasks in WaitStatus
the lack of this logic was causing a panic,
given that for now we expect the new status to be used
only on new system revert is not an issue. But if we started
using WaitStatus in preexisting system/scenarios we would
have to think how to deal with this backward incompatibility
* overlord: switch logic to use WaitStatus instead of HoldStatus
* tests: enable kernel refresh testing
the gadget case is still not working, needs more investigation
* tests/fde-on-classic: re-enable test for gadget updates
which was failing because two reboots were happening as the kernel
command line from the manually written grub.cfg was not matching the
one shipped by snapd.
* tests/fde-on-classic: make sure that modeenv kernel command line
matches the one in snapd/grub.cfg.
* tests: check in fde-on-classic test that remote host has no reboot scheduled
* boot: add debug about cmdline updates
* tests: cherry pick https://github.com/snapcore/snapd-testing-tools/pull/33
* tests: update nested fde-on-classic cmdline to match what grub-recovery.cfg writes
Co-authored-by: Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
Merge pull request #12235 from pedronis/has-fde-setup-hook-standalone
we need to check for hook presence also in kernels that are not the currently installed kernel if any
MakeRunnableSystem implicitly assumes that the run system is a clone
of the current system, usually a UC20 ephemeral mode system
introduce MakeRunnableStandaloneSystem that does not make this assumption
and use it for the finish step of the install API
in theory we could change MakeRunnableSystem itself not to make the assumption
but it changes a bit its properties so it is something to maybe consider for
later
