When the "snap-tool" script encounters a core snap it will switch to
the "stable" channel if the channel was set to "stable/ubuntu-X.X". This
ensures that core snaps always come from one canonical source.
ubuntu-cdimage/debian-cd/tools/add_live_filesystem helpfully adds a
'filesystem.' prefix to the squashfs, hence the name of the file
didn't match what's on disk.
grub-probe must not be called during image build so grub is diverted. In
multilayer image the chroot is always the tip of the filesystem, so we
divert grub at the beginning of each pass and undivdert it as the end.
For flat images, it's diverted just before building the chroot and
undiverted after.
UbuntuStudio image builds have recently begun failing as a result of adding a
grub theme customization to their flavor, which they then try to apply by
running update-grub from their maintainer scripts. This fails with:
Setting up plymouth-theme-ubuntustudio (0.57) ...
update-alternatives: using /usr/share/plymouth/themes/ubuntustudio-logo/ubuntustudio-logo.plymouth to provide /usr/share/plymouth/themes/default.plymouth (default.plymouth) in auto mode
update-alternatives: using /usr/share/plymouth/themes/ubuntustudio-text/ubuntustudio-text.plymouth to provide /usr/share/plymouth/themes/text.plymouth (text.plymouth) in auto mode
update-initramfs: diverted by livecd-rootfs (will be called later)
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
dpkg: error processing package plymouth-theme-ubuntustudio (--configure):
installed plymouth-theme-ubuntustudio package post-installation script subprocess returned error exit status 1
Packages providing grub themes should be able to call update-grub from their
maintainer scripts, and they should be able to be installed under
livecd-rootfs. It's surprising to me that this hasn't been a problem before
now for any flavors.
We know that grub-probe should not be called as part of an image build, so
just use our standard helper function to divert it before running the chroot
stage and undivert it after.
When the magic-proxy script could not find a valid InRelease file for the
configured timestamp, it would fall back to serving the canonical version
of it. This meant that builds would succeed, even though snap-shotting the
repository failed.
This update makes the script return HTTP 404 when an InRelease by-hash
link for a given combination of mirror, suite and timestamp cannot be
found.
Installing policyrcd-script-zg2 doesn't quite do this because of the way
that live-build installs its own temporary version of policy-rc.d. The
only remotely sensible way I can see to deal with this is to create the
symlink manually.
Remove wants from local-fs.target, add wants from the uuid device instead.
Tested by applying these changes from pre-pivot-root by modifying
/root files in place whilst booting with break=bottom.
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
When the REPO_SNAPSHOT_STAMP variable is set, the auto/build script will attempt
to launch a transparent HTTP proxy on port 8080, and insert an iptables rule to
redirect all outgoing HTTP requests to this proxy.
The proxy, contained in the `magic-proxy` Python script, examines each request
and silently overrides those pointing to InRelease files or files that are
listed in InRelease files. It will instead provide the contents of the requested
file as it was at REPO_SNAPSHOT_STAMP, by downloading the corresponding asset
"by hash".