Private store may not contain lxd snap

[Aristo Chen]

Hi,

I defined core22 and snapd in extra-snaps, but the ubuntu-image 3.x will also try to download lxd snap after downloaded core22 and snapd, and lxd is actually not included in the private store

If I understand correctly, in internal/statemachine/classic_states.go, the function prepareClassicImage will try to check the file called var/lib/snapd/state.json, and tries to preseed the snaps defined in that file afterwards. However, lxd snap may not be included in private store, then it will fail to preseed the snap.

Previously in ubuntu-image 2.x, we leveraged the commit(https://git.launchpad.net/livecd-rootfs/commit/live-build/functions?id=b43e3b84f4c9100379f4686f80699929c7657056) from foundation team, I don't know if this mechanism should be integrated into ubuntu-image 3.x as well? Or maybe we can have a flag to skip checking var/lib/snapd/state.json?

[Paul Mars (upils)]

As discussed in mattermost, ubuntu-image 3.X also reset the preseeding if needed. See https://github.com/canonical/ubuntu-image/blob/main/internal/statemachine/classic_states.go#L776.

> we leveraged the commit

What do you mean?

> Or maybe we can have a flag to skip checking var/lib/snapd/state.json

You mean reset the preseeding anyway? Or skip the preseeding entirely?

I am also not sure to understand why your problem is linked to resetting the preseeding.

[Aristo Chen (aristochen)]

> What do you mean?

Previously, when we were using u-i tool 2.x to build 22.04 classic image, we had a hook(https://git.launchpad.net/~lyoncore-team/lyoncore/+git/iot-image-builds/tree/hooks/post-populate-rootfs.d/030-snap-prepare-image.sh?h=classic22.04-uimg2#n17), and the code was copied from foundation team by one of my colleagues in CE team AFAIK

> You mean reset the preseeding anyway? Or skip the preseeding entirely? I am also not sure to understand why your problem is linked to resetting the preseeding.

I think the root cause is var/lib/snapd/state.json is not handled properly. By deafult, there is lxd and core20 snap in that file(var/lib/snapd/state.json), but the customer may not want to include those snaps in their private store, so skip checking that file((var/lib/snapd/state.json)) could solve this issue, or probably we can remove that file(var/lib/snapd/state.json) directly? I am not sure if remove the file(var/lib/snapd/state.json) will affect any other use cases, so that's why I think having a flag somewhere(probably in the yaml?) could be better

[Paul Mars (upils)]

You are currently building the image based on a existing tarball (see https://pastebin.ubuntu.com/p/mM8Dh7tSXh/). The `/var/lib/snapd/state.json` file (see https://pastebin.ubuntu.com/p/jcQcC73wrd/plain/) contains lxd in it.

> By deafult, there is lxd and core20 snap in that file(var/lib/snapd/state.json)

What do you mean? Is that because lxd is in `/var/lib/snapd/state.json`?

I suppose you could maybe remove lxd from the state.json before building the image. I understand in the hook you mention the solution was to completely nuke snapd, remove the state.json file and reinstall snapd. It feels a bit extreme and I suspect we might lose some information.

I will need to think more about it to define what would make sense in ubuntu-image. I am not sure a flag to skip/remove the existing `/var/lib/snapd/state.json` would be the best idea. If we take a step back I think here we are trying to deal with an "imperfect" pre-existing tarball rootfs. I need to determine what we want to support in ubuntu-image and even if this is the responsibility of ubuntu-image to fix this.