I’m getting a bunch of this error in my boot logs on initial boot with my Core18 image, and it seems to be affecting the Snap Daemon’s ability to run.
Jun 11 13:37:22 localhost snapd[3129]: helpers.go:961: cannot retrieve info for snap "kernel": cannot find installed snap "kernel" at revision unset: missing file /snap/kernel/unset/meta/snap.yaml
Surrounding this error are messages from snapd starting and stopping over and over. I will say that my kernel snapcraft.yaml file is perhaps not in the right place, since it’s placed at /snap/snapcraft.yaml. Should the snapcraft.yaml file be placed in the root of the kernel directory? Additionally, I believe that unset is referring to the revision? How do I give it a revision?
I build the kernel snap myself using the mainline 5.4.x kernel. I have an entry in my assertion for "kernel": "kernel", (the kernel directory is obvs in the same directory as the assertion).
If it matters, I don’t have a revision number in my assertion model.
well, either something is wrong with your kernel snap (missing meta/snap.yaml (whch is generated from snapcraft.yaml during build)) or you did not properly specify the path in the --snap commandline option for ubuntu-image when building the image (unless you have a brand store i assume your kernel is locally ?)
I don’t believe that meta/snap.yaml is created when I build. Can you elaborate on that? Why might that be?
We do not have a brand store, so yeah, everything is built locally from a git repo.
The build process drops a kernel_5.4_armhf.snap file into the kernel/ directory when its finished, so in my ubuntu-image command I just add a --snap kernel/kernel_5.4_armhf.snap option.
This is the issue for sure then. A kernel snap and all snaps by definition need to have snap.yaml. This should have been generated for you by snapcraft if you are using snapcraft to build the kernel snap.
Actually, scratch that, I appear to have the same contents. However, in my directory where it’s built, I don’t see that dir. (Forgive me, I’m not terribly familiar with snaps)
squashfs-root/meta
squashfs-root/meta/snap.yaml
and snap.yaml is not empty. However, it is just in the base of the .snap, and not in any unset/ directory, like my image is (apparently) expecting.
Unfortunately, it’s confidential. I can say that it came from a Core16 build that seemed to work pretty well, though I don’t know if the error in question happened on that one. Also, I bumped the kernel version from 4.14 to 4.19 and then 5.4.
What is the base of the kernel snap you built ? I.e. the kernel snap in the snap.yaml should have base: core18 in it since you are building a UC18 image.
Also similarly, does the gadget snap you are using have a base: core18 in it too?
well, it is sadly a bit tricky to go deeper in support without access to the model assertion, snapcraft.yaml of the kernel and the gadget source …
the revision should be set by ubuntu-image during image creation … (for an initial sideloaded kernel this is usually “x1”) but for some reason this did not happen.
A shot in the dark I was thinking of, though, is there a reason anyone can think of off the top of their head that the image is expecting the snap.yaml file at unset/meta/snap.yaml instead of… well, anywhere else?
thats your prob … there should be a version (for properly released snaps it is the store revision. for sideloaded snaps (ie. via using the --snap option in ubuntu-image or from cmdline via --dangerous when installing an app snap) a revision number of xN is genereated at snap install time (N being an iterative number) somehow you did not get this generated revision number and something falls back to “unset” …