These are currently applied with hacks in the core18 repo when building the
core18 snap, but that was always meant to be a temporary thing until it was
upstreamed... here's the upstreaming.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
On Core20 devices, the user may decice to invoke a recovery chooser by holding
down a specific key. Make sure that the recovery chooser trigger detection
service runs before, so that by the time console-conf runs, the trigger
detection window is closed and we may launch the chooser if needed.
Note, the patch only includes the bits for ensuring the correct order during
boot.
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
The service is named core.start-snapd.service in core20. Add a comment
explaining why we need this.
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
On core18 the firstboot seeding happens via the core18.start-snapd
service. This service will do the initial start of snapd when the
system is unseeded. This service will wait until the system is
fully seeded.
We cannot run console-conf before that because it uses the "snap"
command which will not be available before the system is seeded.
Once that has landed https://github.com/snapcore/core18/pull/74
can be reverted (in fact the hooks/200-console-conf-after.chroot
file can be removed entirely).
Look for the marker file left by snapd recovery chooser user request detection
and attempt to run the chooser.
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
This makes things a bit more generic, because I am going to need to
track which partition table type a disk originally.
The special cases around swap are annoying.
The installprogress controller waits for various model objects to be
configured before proceeding. But model objects whose state was loaded
from disk after a snap refresh were not marked as configured :( This
meant that, in particular, the postinstall steps waited on the language
being configured indefinitely. The fix is simple: mark model objects as
configured when their state is loaded from disk post-refresh.
if we want to do things after install has completed (e.g.: run late
commands), we can't have the code that runs the install invoking
/sbin/reboot directly.
Michael Hudson-Doyle