The daemon=true config is not set on Ubuntu Core during installation

[jrmcpeek]

With the following snaps:

Name              Version                 Rev    Tracking       Publisher   Notes
core22            20231123                1033   latest/stable  canonical✓  base
mesa-core22       23.0.4                  231    latest/stable  canonical✓  -
pc-kernel         6.2.0.37.38~22.04.15    1516   22-hwe/stable  canonical✓  kernel
snapd             2.61.1                  20671  latest/stable  canonical✓  snapd
ubuntu-frame      123-mir2.16.1           8225   22/candidate   canonical✓  -
ubuntu-frame-osk  49-squeekboard-v1.17.1  372    22/stable      canonical✓  -
ubuntu-frame-vnc  45-wayvncv0.6.2         226    22/stable      canonical✓  -

Note: 22-hwe/stable and 22/candidate are in use, related to #160.

According to the documentation (https://mir-server.io/docs/run-ubuntu-frame-on-your-device), the daemon config value should default to true on Ubuntu Core devices:

If you are using Ubuntu Core, you can skip this next step. On other versions of Linux, Ubuntu Frame does not start by default. To change this default run the following command:

$ snap set ubuntu-frame daemon=true

This behavior used to work as documented.

I wonder if daemon no longer getting set to true is related to:

• https://github.com/MirServer/ubuntu-frame/pull/155
• https://github.com/MirServer/ubuntu-frame/commit/8cb0ee65c40a6d1b0ef2ef524785f4f96d1a5ce2

Running the previous install check:

if grep -q -e snap_core= -e snapd_recovery_mode= /proc/cmdline
then echo "daemon=true"
else echo "daemon=false"
fi

The script successfully prints out daemon=true.

Attempting to run the current install check:

if ! snapctl model > /dev/null || [ "$( snapctl model | awk '/^classic:/ { print $2 }' )" = "true" ]
then echo "daemon=false"
else echo "daemon=true"
fi

The script produces:

error: error running snapctl: insufficient permissions to get model assertion for snap "ubuntu-frame"
daemon=false

And, that test script matches the post-installation state:

Service                         Startup   Current   Notes
ubuntu-frame.daemon             disabled  inactive  -
ubuntu-frame-osk.daemon         enabled   active    -
ubuntu-frame-vnc.daemon         enabled   active    -

[Saviq]

Thanks @jrmcpeek for the detailed report, as usual. Something must've changed (in snapd?) that no longer allows snapctl model to work. We'll dig.

[Saviq]

@jrmcpeek I reported this on snapd, will come back here when we know more.

https://bugs.launchpad.net/snapd/+bug/2048508

[jrmcpeek]

Thanks for the quick response as always @Saviq!

[Saviq]

@jrmcpeek hey, what's the output of snap model on your device? Are you running a custom image by any chance? Indeed this will only work on devices with the stock Canonical image, see:

https://bugs.launchpad.net/snapd/+bug/2048508/comments/1

If you're building a custom image, you should simply set daemon: true in your gadget for the affected snaps.

I'll be updating the documentation to highlight this requirement.

[jrmcpeek]

@Saviq - Yes, we're running a custom image with a private brand store.

Before I make the changes on our side to force this, I wonder if:

Could the decision be inverted? That is, default to daemon=true unless you specifically determine the environment is classic?

Alternatively, could a combination of "the old" detection and "the new" detection be used to reconcile this?

The reason I ask is, for core devices - inclusive of custom core images - I would still expect the desired, default state is that:

• The device is provisioned with its base snaps, as defined in its model assertion
• The device provisioning is likely desired to be automated and low-touch

With those, it seems odd that every custom builder would need to go out of their way to explicitly set this to get the previous default behavior

[Saviq]

@jrmcpeek the problem is that snapctl model failing is currently what determines to be classic (model: classic is only there on TPM-backed Classic installs)… obviously not reliably enough.

Yes, I will look for a way to more reliably determine that we're on classic, but regardless it's appropriate to reduce indeterminism in your custom images (and avoiding the check altogether) since you know you want those daemons to run.

[jrmcpeek]

... obviously not reliably enough.

Only showing up if it's a TPM-backed Classic install helps explain the challenge then 🙂.

I assume that's also why the original check is no longer sufficient - TPM-backed Classic installs would also match the grep check. Is this correct?

In either case, we'll assume that we need to explicitly set daemon=true as part of provisioning at this point.

At this point, I think the issue can be closed, unless you'd like to leave it open until documentation - or better classic detection investigation - is completed.

[Saviq]

I assume that's also why the original check is no longer sufficient - TPM-backed Classic installs would also match the grep check. Is this correct?

Exactly, that's what's triggered the change.

In either case, we'll assume that we need to explicitly set daemon=true as part of provisioning at this point.

At this point, I think the issue can be closed, unless you'd like to leave it open until documentation - or better classic detection investigation - is completed.

Right indeed. I'll keep it open until we decide which direction to take.

[mapero]

Hi, we run in exactly the same issue. Our devices are linked to our brandstore and have their own model. But the snap is not provided in the image, it can be installed by the user of our device. It is not available initially and our customer do not have any access to the cli to set the configuration.

We would prefer to have the option defaulting to daemon=true on core systems.

Is there already a decision in which direction you go?

Thanks.

[AlanGriffiths]

We would prefer to have the option defaulting to daemon=true on core systems.

That is our preference too. Our problem, as discussed above, is reliably identify core and classic systems. Once we have solved that we will post an update.

[mapero]

Would it be an option to parse the /etc/os-release and if it is not core assume it is classic? As far as I know, it is accessible from within the snap.

[AlanGriffiths]

Would it be an option to parse the /etc/os-release and if it is not core assume it is classic? As far as I know, it is accessible from within the snap.

No. From within the snap /etc/os-release comes from the base snap.

On some systems, /etc/lsb-release is from the host system, but we would need understand what the guarantees and failure modes are before relying on it. (We've already had two iterations where our assumptions were invalidated, we want to solve this right.)

[Saviq]

It is not available initially and our customer do not have any access to the cli to set the configuration.

You should still be able to set the defaults: configuration in the gadget, even if it's not installed at first?

Edit:

Like here: https://mir-server.io/docs/configuring-ubuntu-frame-through-a-gadget-snap

[mapero]

It worked, but requires that the gadget with the setting is updated before installing the ubuntu-frame snap.

[Saviq]

Yeah I think part of the learning here is that in custom gadgets you should really not rely on defaults, and be explicit about your desired configuration. Something to add to our documentation.

[bugraaydogar]

There is also snapd-rest-api which can be used to set ubuntu-frame's deamon configuration for this purpose rather than using gadget's default section.

[mapero]

@bugraaydogar That is correct, but this will make ubuntu-frame even more coupled to our system. The ubuntu-frame is an optional feature that can be installed to our system, and from my opinion it should start in daemon mode by default. It should not be necessary, to check if it is installed and than call a specific configuration to make the deamon enabled.

I think snapd should provide a dedicated way to identify if the system is classic or not, because identifying from within a snap that the system is classic might be useful for other use cases as well.

[mapero]

Any update or roadmap on this one?

[Saviq]

Hi @mapero, while this may be something solvable in the future, the best approach today is to encode the defaults in your custom gadget, as per:

https://mir-server.io/docs/configuring-ubuntu-frame-through-a-gadget-snap

Just add daemon: true as the default for the Frame snap and it will get applied upon installation of the snap:

defaults:
  BPZbvWzvoMTrpec4goCXlckLe2IhfthK:
    daemon: true