> 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.
You are currently building the image based on a existing tarball (see https:/ /pastebin. ubuntu. com/p/mM8Dh7tSX h/). The `/var/lib/ snapd/state. json` file (see https:/ /pastebin. ubuntu. com/p/jcQcC73wr d/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.