Seeing any snap via snap_preseed will evaluate the base for each snap
and seed the appropriate base. There should be no reason to explicitly
seed the 'core' snap and with snaps moving to 'core18' this will add
'core' without need.
The _snap_post_process function is meant to install snapd if core18 is the
only core snap installed or removed snapd if core is installed and snapd
was not explicitly installed. But the current logic in _snap_preseed
will never call _snap_post_process. $core_name will never be empty
with the existing logic, but even if it were that would only be for the
'core' snap and we'd miss using the 'core18' logic that pulls in snapd.
Given the case statement in _snap_post_process can handle doing the
right thing given any snap we can just call it unconditionally.
Back in 2017 some code was added to ignore failures tearing down loop
devices. But debugging that growpart race on cloud images made me (very)
aware of a potential cause of the race: doing something like zerofree on
a device will cause udev scripts to run, and if they are still running
by the time kpartx is called, you would expect the kpartx -d to fail. So
lets see if a udevadm settle helps, and get rid of one of the "sometimes
this fails but we don't know why" comments...
With the removal of snap-tool failures are seen in image builds that do
not have the 'core' snap included by the seed. This is the case for the
minimized subproject of the ubuntu-cpc project where lxd/core is removed.
In that subproject, any binary hook which adds a snap that is based
on 'core' will not add 'core' and fail 'snap debug validate-seed'.
snap-tool included the following logic in the 'snap-tool info' when
determining snap bases:
# Have "base" initialized to something meaningful.
if self.is_core_snap():
snap_data["snap"]["base"] = ""
elif snap_data["snap"].get("base") is None:
snap_data["snap"]["base"] = "core"
The snap store does not return a base if the base is core which makes
this necessary. This patch looks for the base in 'snap info' output
and if none is found (and the snap is not snapd or core) it assumes the
base is 'core' and installs it. This restores the behavior lost in the
migration from snap-tool to snap cli.
snap-tool was added to support a deprecate cohort-key feature of the snap store.
Recent changes in snap assertions have added additional fields which snap-tool
is not retrieving. This resulted in snap install failures on first boot.
This patch removes snap-tool and returns to using the snap cli. This ensures
snap downloads will function without odd incompatibilities.
When getting the list of snaps to include on an image via germinate, we
process the snaps in alphabetical order. Currently we seed several
packages `gnome-foo` and also `gtk-common-themes`, the default provider
of `gtk-3-themes`. Since `gtk-common-themes` is alphabetically after
`gnome-foo`, the `seed.yaml` we generate is invalid when we are part way
through generating.
What we really care about, though, is not that the `seed.yaml` is always
valid at every step, but it is that it is valid at the *end* of seeding.
So for the germinate case, let's defer validation to happen once at the
end. Other callsites of `snap_preseed`, where callers are careful to
seed snaps in the right order, are unaffected by this.
This is apparently still required; without it snapd gives an error
message like:
stateengine.go:102: state ensure error: devicemgr: cannot proceed without seeding "core"
Util-linux 2.33 fixed mount --rbind --make-rslave which did not pass MS_REC
with MS_BIND and livecd-rootfs did only --bind --make-rslave effectively with
prior mount versions.
While mount --rbind --rslave are properly passed the flags to mount()
unmounting did not work cleanly with --make-rslave.
To clearly stop propagation of umount, --make-private is used instead of
--make-rslave and it is always set before umounts. Umount -R is replaced
with a simple umount since submounts are tore down in teardown_mountpoint()
earlier.
LP: #1813730
The generic assertion will be put in place if there are preseeded snaps.
A hook that wants to add its own model should be able to overwrite
the generic assertion. This patch allows a hook to continue unchanged
calling snap_prepare_assertions with a custom brand/model. The patch
will replace the generic brand/model if a custom brand/model is specified.
Prior to this patch the generic brand/model would remain in place.
There can only be one model assertion, so we don't need to disambiguate them.
This also brings us in line with the behaviour of `snap prepare-image`, and
consistency is nice.
This also splits up the preparation in to two functions, so that images that
want to use a custom model assertion but don't have any snaps to preinstall
don't end up with the core snap installed.
When no channel is given for a pre-seeded snap, the channel
should be stable/ubuntu-XX.YY to match Ubuntu policy.
This patch adds the LB_DISTRIBUTION var to config/{binary,chroot}
to have a common way of determining the Ubuntu XX.YY version
number between hooks and auto/build.
* Only shell out to set $account when we need to use it.
* Reduce scope of $account to make it local to the function
* Fix indenting within an 'if' block
instead of having bogus root=stuff arg generated in grub.cfg, it is
actually empty. Therefore update the sed command to make the arg in
the root= token optional. This should resolve non-booting livecd cpc
images.
unmount them, instead of working from a hard-coded list. This makes
the code resilient against other submounts being added later, including
downstream.
* Also nuke the sleep / udevadm settle calls in the process, which should
never be required and slow down the builds.
* live-build/ubuntu-cpc/functions: Add a function, teardown_mountpoint,
to reverse the work done in setup_mountpoint. Lack of this function
has forced users of setup_mountpoint to implement this separately
and the implementations have diverged. (LP: #1716992)
* live-build/ubuntu-cpc/functions: Remove umount_settle function.
The was only used where teardown_mountpoint was lacking.
we don't have to leave empty space in our derivative images for packages
that have been downloaded/installed/removed. This normally isn't
relevant for the installed system, since the root filesystem will
auto-expand in place on the target disk, but lets us ship smaller
images.
* live-build/functions: also call 'apt-get update' after mounting the
blank /var/lib/apt.