Core18: Cannot retireve info for snap "kernel": cannot find installed snap "kernel" at revision unset: missing file /snap/kernel/unset/meta/snap.yaml

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?

Thanks!

how does your model assertion look, where does that kernel snap come from ?

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.

here is a self-build kernel snap i’m using:

ogra@pi4:~$ sudo unsquashfs -l /var/lib/snapd/snaps/linux-raspberrypi-org_x22.snap | grep /meta
squashfs-root/meta
squashfs-root/meta/snap.yaml

check yours with unsquashfs -l

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.

can you show us the snapcraft.yaml of your kernel or is that confidential ?

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?

for the kernel snap it needs to be build-base: else snapcraft is confused IIRC

1 Like

Ah yes indeed base should not be in the kernel snap, but the gadget should have a base.

Everything has core18 as base. And yea, I remember having an hour or two of trouble a few weeks back with that build-base thing haha.

but base shouldnt really play a role at all …

works fine without any base set (using it in a personal Pi4 UC18 image (in fact this is the code for the above snap using “unsquashfs -l”)) …

Yea I mean, the image eventually boots, this is just one of several issues that I think is pushing my boot times to >10 minutes.

Ogra knows that I’m also having a lot of trouble with serial-getty :stuck_out_tongue:

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.

Right. Sorry about that :sweat:

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 :slight_smile: … 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” …

Can I specify it somehow? Where would I do that?