When building on LP, the mock snap files generated with mksquashfs end up having
the same sha3-348 digest, despite forcing a 1s delay between consecutive snap
builds, what should have affected the internal file timestamps. As a workaround,
use a different content of mock files, such that the files must yield a
different digest.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk`
The current snap-bootstrap has a race when mounting the seed
partition in `mountNonDataPartitionMatchingKernelDisk` on EFI
systems.
The code determines the partUUID of the disk that booted the
kernel by reading the EFI LoaderDevicePartUUID variable. However
there is no guarantee that this partition is available when
snap-bootstrap runs, the kernel may still enumerate the HW.
This can be observed on a fast NUC when booting from a USB
stick.
Note that the `the-tool.serice` already has a
"After=systemd-udev-settle.service" set but that is still
racy because any `udev settle` (or `udev trigger --settle`)
is racy, the only option is to poll for the part uuid to
appear.
This is a minimal commit to avoid too much churn in code.
Thanks to Sertac for reporting this bug.
* snap-bootstrap: rework waitPartSrc to improve testing (thanks to Alberto and Ian)
* snap-bootstrap: show a log message if waitPartSrc needs to wait
If waitPartSrc needs to wait for the device this commit makes it
show a logger.Noticef() message. The message is only shown once
because waiting for the device is usually super quick and if it
is not that is most likely an error anyway so spamming the
terminal will not help.
* snap-bootstrap: add test that ensures that if no waiting is needed for partSrc no log message is displayed
* snap-bootstrap: rename waitPartSrc -> waitFile
* snap-bootstrap: fix time.Duration() casting on 32bit systems
* snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk`
The current snap-bootstrap has a race when mounting the seed
partition in `mountNonDataPartitionMatchingKernelDisk` on EFI
systems.
The code determines the partUUID of the disk that booted the
kernel by reading the EFI LoaderDevicePartUUID variable. However
there is no guarantee that this partition is available when
snap-bootstrap runs, the kernel may still enumerate the HW.
This can be observed on a fast NUC when booting from a USB
stick.
Note that the `the-tool.serice` already has a
"After=systemd-udev-settle.service" set but that is still
racy because any `udev settle` (or `udev trigger --settle`)
is racy, the only option is to poll for the part uuid to
appear.
This is a minimal commit to avoid too much churn in code.
Thanks to Sertac for reporting this bug.
* snap-bootstrap: rework waitPartSrc to improve testing (thanks to Alberto and Ian)
* snap-bootstrap: show a log message if waitPartSrc needs to wait
If waitPartSrc needs to wait for the device this commit makes it
show a logger.Noticef() message. The message is only shown once
because waiting for the device is usually super quick and if it
is not that is most likely an error anyway so spamming the
terminal will not help.
* snap-bootstrap: add test that ensures that if no waiting is needed for partSrc no log message is displayed
* snap-bootstrap: rename waitPartSrc -> waitFile
* snap-bootstrap: fix time.Duration() casting on 32bit systems
osutil/disks: support filtering by mount opts in MountPointsForPartitionRoot
Rename RootMountPointsForPartition -> MountPointsForPartitionRoot as suggested by Alberto, and expand it to support filtering by mount options since we will need to ensure we are only using rw mounts when actually performing gadget asset updates.
Also address some comments in #10862 and #10857.
* daemon: introduce system-restart-immediate flag in the snaps APIs
this gets reflected on the Change
* overlord: make Changes respect system-restart-immediate
have all system restart requests that don't use Now already
use snapstate.RestartSystem which consults system-restrat-immediate
on the Change as set by daemon
* daemon: introduce system-restart-immediate flag in the snaps APIs
this gets reflected on the Change
* overlord: make Changes respect system-restart-immediate
have all system restart requests that don't use Now already
use snapstate.RestartSystem which consults system-restrat-immediate
on the Change as set by daemon
This is needed because we want to be sure we can write to the mountpoint
directory we find for the partition, there is a chance for UC20 systems that we
could get the /var/lib/snapd/seed mountpoint for the ubuntu-seed partition when
searching and that would be read-only, but when doing gadget asset updates we
want to be able to write to the partition, so this lets us filter the resulting
mount points by their mount options.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Also simplify an if condition to roll two checks into the same if.
Thanks to Maciej, Alberto and Michael for these suggestions.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
