The tests seem to call real depmod which fails when building on LP:

```
----------------------------------------------------------------------
FAIL: setup_test.go:770: setupSuite.TestRemoveKernelModulesComponentsFails

setup_test.go:786:
    s.testSetupKernelModulesComponents(c, firstInstalled, nil, ksnap, kernRev, "")
setup_test.go:709:
    c.Assert(err, IsNil)
... value *exec.Error = &exec.Error{Name:"depmod", Err:(*errors.errorString)(0x4000118380)} ("exec: \"depmod\": executable file not found in $PATH")

----------------------------------------------------------------------
FAIL: setup_test.go:656: setupSuite.TestSetupAndRemoveKernelModulesComponents

setup_test.go:662:
    // Set-up and then remove
    s.testSetupKernelModulesComponents(c, toInstall, nil, ksnap, kernRev, "")
setup_test.go:709:
    c.Assert(err, IsNil)
... value *exec.Error = &exec.Error{Name:"depmod", Err:(*errors.errorString)(0x4000118380)} ("exec: \"depmod\": executable file not found in $PATH")

----------------------------------------------------------------------
FAIL: setup_test.go:666: setupSuite.TestSetupAndRemoveKernelModulesComponentsWithInstalled

setup_test.go:672:
    s.testSetupKernelModulesComponents(c, firstInstalled, nil, ksnap, kernRev, "")
setup_test.go:709:
    c.Assert(err, IsNil)
... value *exec.Error = &exec.Error{Name:"depmod", Err:(*errors.errorString)(0x4000118380)} ("exec: \"depmod\": executable file not found in $PATH")

OOPS: 164 passed, 3 FAILED
```

Make sure to have a default mock which fails and a mock the appropriate variant
in tests which require it.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

It is needed now on hybrid systems to be able to build the drivers
tree.

…snapcore#13835)

link. As sealing is taking longer than in the past.

* tests: fix fake-netplan-apply test

The test was meant to fail in a clear way on unsupported releases but due to an
unintentional refactor, it was just running on the wrong base.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

* tests: fake-netplan-apply equate jammy and mantic

Co-authored-by: Zeyad Yasser <zeyady98@gmail.com>

* tests: install core24 from edge for fake-netplan-apply

The netplan-snap is removed so that we can remove the base later.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

---------

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Co-authored-by: Zeyad Yasser <zeyady98@gmail.com>

…13839)

The one from edge will always fail if we have FDE, make sure that
there are no false negatives because of that.

Ship the current version of snap-debug-info.sh script inside the snapd snapd, so
that folks no longer need to download it from snapd github repository.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

We do not need early mounts for the kernel in UC16/18, and causes
problems with systemd on UC16.

This fixes access to /etc/apparmor.d/tunables when running from snapd snap.
When snapd snap re-executes, and uses apparmor_parser from snapd snap (those
are separate conditions), then it re-directs the parser away from host
/etc/apparmor.d and we have special code to load tunables from the host anyway.
Those tunables are themselves conditional on the conditional include syntax
that may or may not be supported by apparmor (otherwise the would be explicitly
spelled out in the template, and not dynamically expanded with custom logic).

The problem was introduced along with patch
b98e4af (i/apparmor: support for home.d
tunables from /etc/ (snapcore#13118)), as the case for snap-update-ns was missed, and
the default expansion is an empty string.

Regression-testing this requires that we re-package snapd snap, so the test
will come in with a separate patch as it requires somewhat more effort to
behave correctly.

This issue was identified by Maciej Borzecki.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…napcore#13842)

* o/snapstate: store unlinked component information in change

As we will need this information in the component discard task.

* o/snapstate: discard previous component on a component refresh

Only one can be installed in the system at the same time.

* tests/component: check removal of older component after refresh

* o/snapstate: add function to retrieve component setup

Add function to find ComponentSetup for a task that is part of the
tasks created to do a component operation.

* o/snapstate: store unlinked component in ComponentSetup

* o/snapstate/backend: remove component related directories if empty

* o/snapstate: use SnapSetup to store the previous kernel revision

instead of having an object directly in the change.

* o/snapstate: store unlinked component in setup task

* o/snapstate: set previous kernel in setup task

instead of making it part of SnapSetup.

* o/snapstate: some additional tests

Ever since snapd 2.62 was released, snap-update-ns requires opening the home
directory of the user for some validation and sanity checking. This is now
affected by a bug in base policy regarding ecryptfs. Add the similar workaround
we have in other templates.

Fixes: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2062330
Fixes: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2062173

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…ore#13858)

I've noticed this denial in one of my test systems:

  kwi 19 10:54:52 ubuntu-2204-cryptfs kernel: audit: type=1400
  audit(1713516892.723:323): apparmor="DENIED" operation="open" class="file"
  profile="snap-update-ns.chromium" name="/var/lib/snapd /" pid=8425 comm="5"
  requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Given that snap-update-ns must access mount profiles and contains code to
safely traverse a path without any symbolic links, I think the extra
permissions is acceptable.

I did not audit the code to pinpoint the exact cause.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…ainer (snapcore#13859)

* cmd/libsnap-confine-private: helper for detecting if executing inside a container

Add a helper which attempts to detect if the current process is executing inside
a container environment. Specifically, look for /run/systemd/container and check
whether it is non empty.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

* cmd/snap-confine: do not setup device cgroup if running inside a container

Do not set up a device cgroup filter, if we're running inside the container. The
rationale is that the container environment has already shut down device access
sufficiently, and especially if running in unprivileged container, we may not be
able to set it up correctly anyway.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

* cmd/snap-confine: allow reading of /run/systemd/container

Allow snap-confine to read /run/system/container to implement container
execution check.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

* cmd/snap-confine: use strnlen for sc_is_container

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

---------

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Co-authored-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…napcore#13872)

Since 3cfa28a snap-confine checks if the system is running in a container. It
does so by reading /run/systemd/container. Extend the SELinux to allow basic
search operations within /run/systemd. It is unlikely anyone runs snapd in a
container where the SELinux is enabled on the host, so the actual file read
permissions are likely not needed.

Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

…e#13874)

The test uses host parser unconditionally, which may not understand
future syntax that is present in cases when apparmor is carried
by snapd snap package.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…generation (snapcore#13847)

The nvidia container toolkit needs to traverse the top level libs
directory in order to discover the libraries and generate a CDI config.

…e#13882)

Snapd from the snap generate udev rules that executes snap-device-helper
from the host. In cases when the snap is newer than the package, the
new command line is rejected by the old snap-device-helper from the
package. Because the new snap-device-helper accepts old command-line,
but just ignores the extra parameters, it is safer for now to generate
rules with the old command line.