While squashfs is always read-only, when mount creates the required
loop device, it does not know that squashfs is a read-only
filesystem. This causes the loop devices for snaps mounted in the
initramfs to be be writable. Since the snaps are stored on
`/run/mnt/data`, it means the `/run/mnt/data` cannot be remounted
read-only.
There is a mount cycle now in Ubuntu Core where `/run/mnt/data` cannot
be unmounted because it contains the snap for the Core snap which is
mounted as root. After switching to the shutdown ramfs, then systemd
tries again to umount the remaining file systems as well as the root
file system. At this point, it still cannot umount `/run/mnt/data`, so
`systemd-shutdown` tries to remount read-only. But since the loop
device for the Core snap that cannot be unmounted is still writable,
then `/run/mnt/data` cannnot be remounted read-only.
This results in Ubuntu Core not properly unmounting `/run/mnt/data`.
This can be seen in the screen or serial console right before powering
off or rebooting:
```
Failed to remount '/oldroot/run/mnt/data' read-only: Device or resource busy
```
With this fix, this error disappears. While other errors about
unmounting are still here, it is safer because everything is
read-only.
* boot,tests: move where we write boot-flags one level up
/run/snapd/snap-bootstrap is a scratch directory and user space
shouldn't care a lot about it
* cmd/snap-bootstrap/initramfs-mounts: fix boot-flags location from initramfs
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Co-authored-by: Ian Johnson <ian.johnson@canonical.com>
It is because there is not match for the brand from recovery and model,
I'll need to add some code to manually update that on the test.
google:ubuntu-core-20-64 .../tests/core/basic20# snap recovery --unicode
never
Label Brand Model Notes
20200915 canonical* ubuntu-core-20-amd64-dangerous current
google:ubuntu-core-20-64 .../tests/core/basic20# snap recovery --unicode
auto
Label Brand Model Notes
20200915 canonical✓ ubuntu-core-20-amd64-dangerous current
google:ubuntu-core-20-64 .../tests/core/basic20# snap recovery --unicode
always
Label Brand Model Notes
20200915 canonical✓ ubuntu-core-20-amd64-dangerous current
google:ubuntu-core-20-64 .../tests/core/basic20# snap model --verbose
brand-id: canonical
model: ubuntu-core-20-amd64-dangerous
serial: ee7845cb-ef5a-40b8-83d7-13654c74ec65
architecture: amd64
base: core20
timestamp: 2020-01-13
google:ubuntu-core-20-64 .../tests/core/basic20# snap model
brand Canonical✓
model ubuntu-core-20-amd64-dangerous
serial ee7845cb-ef5a-40b8-83d7-13654c74ec65
This fixes:
. Matching the right kernel which could be pc-kerne or pi-kernel
. Checking snap recovery output against the model information
These changes are needed to make the test work with external backend on
lab devices
This ensures that during install/recover mode we use symlinks in /var/lib/snapd/snaps to /var/lib/snapd/seed/systems//snaps, and that makebootable will still copy the full snap file to /run/mnt/ubuntu-data/... such that the initramfs and run mode see a normal snap file. Note that we specifically don't want the initramfs to use symlinks from ubuntu-data to ubuntu-seed because this is not trusted, this is enforced by passing a new InstallOptions to Container.Install with a MustNostCrossDevices flag.
This was prompted by https://bugs.launchpad.net/snapd/+bug/1878647 because there, the tmpfs we mount for ubuntu-data/writable is only 205M, and all the kernel and base snaps are over 205M and so the install runs out of space to copy the snap files onto the tmpfs and eventually snapd tries to uninstall itself during first-boot.
This fixes https://bugs.launchpad.net/snapd/+bug/1878647
* boot/makebootable: if kernel,base snaps are symlinks, follow symlink
This ensures that if we switch setup during install/recover mode to use symlinks
in /var/lib/snapd/snaps to /var/lib/snapd/seed/systems/<label>/snaps, that
makebootable will still copy the full snap file to /run/mnt/ubuntu-data/...
such that the initramfs and run mode see a normal snap file.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* snap/squashfs: fix creating symlinks when snap is in uc20 seed system snaps dir
During uc20 install and recover modes, we will have a tmpfs as our writable
partition and as such we don't really want or need to make a full copy of the
snap files into /var/lib/snapd/snaps, and can make do with a symlink instead.
However, during uc20 install and recover modes the snap files from the seed dir
will be of the form /var/lib/snapd/seed/systems<label>/snaps/<name>.snap and so
the previous logic to install it was wrong, as the <name>.snap would not be a
direct child of /var/lib/snapd/seed, and instead needs to check that it is just
prefixed with /var/lib/snapd/seed somewhere.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* snap/many: support InstallOptions + MustCopy for Install()
This will allow us from snapstate to decide how a snap file should be installed,
if it should be symlinked or if it should be always copied, etc. Eventually we
should also introduce logic to snapstate to decide if it should be linked to
remove the overlayfs specific logic from here where it is kind of awkward to
see.
Also add tests for the squashfs and snapstate implementations.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* overlord/snapstate: always copy files when seeding in uc20 run mode
This prevents us from inadventently installing symlinks from ubuntu-data to
ubuntu-seed, which would be insecure in the full disk encryption case because
an attacker could modify ubuntu-seed and after the disk is unlocked on
ubuntu-data and the system starts running, the snap from ubuntu-seed would be
mounted.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* snap: rename MustCopy to MustNotCrossDevices for InstallOptions
This option is really about security and ensuring that when we install a snap
that installation does not cross device/trust boundaries, i.e. on UC20 from
ubuntu-data (trusted) to ubuntu-seed (untrusted), so rename the option to better
reflect this.
Also, refactor the implementation to allow hard-links if MustNotCrossDevices is
true, as by definition hard-links cannot cross devices/filesystems, and really
should only limit symlinks.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* snap/snapdir: un-support MustNotCrossDevices in Install() for now
It's unclear what we want this implementation to look like, so for now just drop
it. `snap try` may be less secure on UC20 as a result, but that shouldn't be
happening on production devices anyways.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/core/basic20: also test that no symlinks were created during seeding
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/core/seed-base-symlinks: disable for UC20 permanently, adjust comment
We don't have symlinks from ubuntu-data /var/lib/snapd/snaps to ubuntu-seed at
/var/lib/snapd/seed by design on UC20 run mode.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/core: fix spread tests adjustments
* squashfs: drop TODO:UC20 more likely to confuse than get ever addressed
Co-authored-by: Samuele Pedroni <pedronis@lucediurna.net>
This commit creates the cloud configuration during install using
the new _writable_defaults mechanism from:
https://github.com/snapcore/core20/pull/46
This allows us to remove the "synced" setting from the writable-path
for the /etc/cloud dir.
