* tests: fix muinstaller tests for 24
* many: build drivers tree when current mount is not the target mount
In some cases (when using the snapd install API or when installing
from initramfs), the place where the kernel snap / components used for the
installation are mounted is different to the final location in the
installed system. This change considers this so the drivers tree is
generated with symlinks pointing to the final expected location.
* overlord: use model to check if we need to set-up drivers tree
instead of using a device context, as for the installation using snapd
API case we have a model but not a context.
* tests/lib/tools/setup_nested_hybrid_system.sh: re-try kpartx -d
* tests/muinstaller-real: check that drivers tree is created
* tests/muinstaller-real: we need a bigger disk with latest kernel
* tests/lib/tools/setup_nested_hybrid_system.sh: clean up
after building muinstaller. On classic we have weird issues otherwise
due to a desktop agent installing lxd.
* tests/lib/prepare-restore.sh: purge lxd-installer
lxd-installer was causing failures in the restore step for 24.04.
Build drivers tree on installation so kernel modules can be found on first boot after installation (otherwise the modules would be available too late, after initial installation of the kernel has happened while seeding).
Also, make sure that the tree is not re-created when seeding, and add a spread test for kernel-modules components.
* dirs: add function to get root of drivers trees
* kernel: do not recreate drivers tree if it already exists
On installation, a drivers tree has already been copied to the data
partition. Do not re-create if found when seeding happens (note though
that on preseeding we will not find the tree and we will still create
it).
* gadget/install: create device tree on installations
Create a device tree on installation so we have it on first boot.
* o/snapstate: fix task message
* tests/nested/manual: add kernel-modules-components test
This test installs a kernel-modules component and verifies that the
shipped kernel module is installed and can be loaded.
* tests/lib: do not error out if cloud-init finished with
'recoverable error' status.
* kernel: have destination as argument when building drivers tree
We need to tackle the generic installation case as opposed to creating
the drivers tree when seeding the system. In that case the destination
tree can vary depending on installation type.
* overlord: pass kernel information to install package
so the drivers tree can be created.
* cmd/snap-bootstrap: build drivers tree on installation from initramfs
* tests: adapt to additional parameters in install.Run
* snap/naming: add ancillary method to split a full component name
into snap and component names.
* gadget/install: fix nosecboot tests
* kernel,overlord: use function from kernel pkg to get kernel early
mount dir.
* o/snapstate/sequence: add ancillary methods to retrieve components
for a given snap revision in the sequence. One of the methods can be
given a component type for filtering.
* o/snapstate/backend: add methods to set-up kernel-modules components
* o/snapstate: add handlers to set-up kernel-modules components
* o/snapstate: add specific setup task for kernel-modules components
* o/{devicestate,snapstate}: change name of kernel set-up tasks
* systemd: add before dependency to early mounts for local-fs.target
So dependencies are the same as when mounting in /snap, as that is
where we will do also the early mounts now.
* kernel: use normal mount points when building drivers tree
* overlord/devicestate: no need to remove early mount anymore
* overlord/snapstate: consider kernel type when ensuring the mounts
* kernel: put modules back in "updates" folder
As that gives priority to the kernel modules under that directory (see
depmod.d(5)).
And ancillary methods:
- KernelVersionFromPlaceInfo, to find the kernel version ("uname -r")
for a mounted snap.
- BuildKernelDriversTree, to build a tree from a mounted snap that can
be bind-mounted to /usr/lib/{modules,firmware}.
These methods are needed to support kernel-modules components.
Replace ioutil.WriteFile with os.WriteFile since the former has been
deprecated since go1.16 and simply calls the latter.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
* many: remove all `device-setup` fde-setup code
When we initially worked on the inline-cryto-engine (ICE) code we
had a design based on the fde-setup hook that would return a
`device-setup` feature as a hint that ICE should be used. It
turned out this design was impractical and we moved to a much
better approach that got merged in
https://github.com/snapcore/snapd/pull/12589
and relies on support for ICE in the kernel and cryptsetup.
With that new approach all the code that was supporting the
`device-setup` approach can be removed now.
* daemon: consider again the fde-setup hook case
* client: consider the ICE encryption type
* osu/disks,kernel: remove device-unlock support as well
---------
Co-authored-by: Samuele Pedroni <pedronis@lucediurna.net>
The unit test is failing in those systems with the following error:
fde_test.go:625:
c.Assert(err, ErrorMatches, `cannot run fde-device-unlock
"device-unlock":
-----
output-only-used-for-errors
service result: exit-code
-----`)
... error string = "cannot run fde-device-unlock \"device-unlock\": exit
status 1"
... regex string = "" +
... "cannot run fde-device-unlock \"device-unlock\": \n" +
... "-----\n" +
... "output-only-used-for-errors\n" +
... "service result: exit-code\n" +
... "-----"
This is happens not 100% of the executions on those systems. It is
causes because the error message is not saved before the script exits
with 1. To deal with this race I added a short sleep in the test script
that is used to mock the fde-device-unlock to make sure the error
message is captured.
Go 1.19 includes some changes to gofmt which intend to make lists and
heading clearer when rendered (https://go.dev/doc/go1.19). This commit
is the result of running the new gofmt and manually fixing some of it.
This was necessary because the new gofmt assumed lines beginning w/ tabs
to start lists or examples. While this is often true in our codebase,
we occasionally also use tabs to indent the lines after a TODO or FIXME
prefix or in yaml (e.g., excerpts of a snap.yaml). This meant that a lot of the
reformatted comments were broken and had to be fixed manually.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
We hit an issue in initrd where the basic.target had an implicit
dependency on the snap-intiramfs-mounts unit. Part of
snap-initramfs-mounts is to use `systemd-run` to run `fde-reveal-key`,
without this `snap-initramfs-mounts` cannot complete. So this
situation lead to a deadlock and an unbootable system.
While this is getting fixed in initrd the fde-reveal-key code should
also be more robust and not hang like this. So this commits adds
`--property=DefaultDependencies=no` which will avoid that fde-reveal-key
needs basic.target to run.
This commit adds a new `systemd.Run()` function that implements
a wrapper around `systemd-run`. This will be used to spawn
commands that use the `--keyring-mode=inherit` when interacting
with the kernel keyring.
EncryptedDeviceMapperName is used to generate the name when installed a device
with ICE.
The DeviceSetupHookPartitionOffset is used to mount a mapper device of the
partition offset to create a header in the offset on the physical partition.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
We need to specify the PartitionName for ICE decryption since it is currently
based on partition name as well as the mapper device provided in Device.
Also allow mocking the actual call to runFDEDeviceUnlockCommand from other
packages without all the complexity of creating hook scripts and such, and add
some more debug logging.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Eliminate the confusion around whether we are mocking systemd-run here, because
we are not mocking systemd-run, we are mocking the hook which systemd-run
executes.
Also check calls to the hook in one of the unit tests which was not doing this.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Add two new functions, IsEncryptedDeviceMapperName to identify if a device
mapper node is with a device-unlock encrypted mapper name device, and
DeviceUnlockKernelHookDeviceMapperHandler to combine the identification with
the task of "un-mapping" the device mapper to the original source disk. Also
register this with the disks package so users of the disks package will get
this built-in when they also import the fde package.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
