are we sure that run/core is not truncated or wrong in some way, you can try snap info --verbose /run/core_3291.snap to see if the signature matches
I don’t understand. /run/core_3291.snap - no such file exists.
sorry, that was the path in the original snapcraft error ?
error: cannot find signatures with metadata for snap "/run/core_3291.snap"
snap info --verbose can be used against any snap file that is known to have failed snap install
Ah okay. Well here’s what it says for the one in the clean lxc I made.
root@unified-snapper:~# snap info --verbose core_3291.snap
path: "core_3291.snap"
name: core
summary: "snapd runtime environment"
notes:
confinement: strict
broken: false
version: 16-2.29~rc1
type: core
sha3-384: bOvT90q93V4uLdCvZKx8krFF5y66BSltpaG9qjX0PYAJJ4L97P-KVRjaE_rcj9aX
ok, notice that snap-revision for 3291 says:
type: snap-revision
authority-id: canonical
snap-sha3-384: ErgE1H1xkfTdWHtguHfHmItnaPYlIpkQxpF23zwQBD9J3Mu0LYk-2hFnn5un8jUj
developer-id: canonical
snap-id: 99T7MUlRhtI3U0QFgl5mXXESAiSwt776
snap-revision: 3291
...
but here:
sha3-384: bOvT90q93V4uLdCvZKx8krFF5y66BSltpaG9qjX0PYAJJ4L97P-KVRjaE_rcj9aX
that snap got broken/corrupted somehow along the way? does it have the right size? should be snap-size: 87810048
wrt those tracebacks, @kalikiana please capture the error code returned from the actual build calls, they shouldn’t be tracebacks at all as a normal error flow causes this.
1 Like
On the host (my laptop) where I am actually using this core snap.
alan@hal:~$ snap info --verbose /var/lib/snapd/snaps/core_3291.snap
path: "/var/lib/snapd/snaps/core_3291.snap"
name: core
summary: snapd runtime environment
notes:
confinement: strict
broken: false
version: 16-2.29~rc1
type: core
sha3-384: bOvT90q93V4uLdCvZKx8krFF5y66BSltpaG9qjX0PYAJJ4L97P-KVRjaE_rcj9aX
How is that calculated?
alan@hal:~$ sha384sum /var/lib/snapd/snaps/core_3291.snap
327f4df864eff28e0174d4128b55309faa5095556f7d6a12b9d4a9c5bc675ac724b9f0f0582baa41a2dffc9674fe86b9 /var/lib/snapd/snaps/core_3291.snap
alan@hal:~$ ls -l /var/lib/snapd/snaps/core_3291.snap
-rw-r--r-- 1 root root 87810048 Oct 23 11:20 /var/lib/snapd/snaps/core_3291.snap
is sha384sum using sha-3 or sha-2?
that core file is corrupted afaict, not sure at all how that happened though:
$ snap download --revision=3291 core
$ grep snap-sha3-384 core_3291.assert
snap-sha3-384: ErgE1H1xkfTdWHtguHfHmItnaPYlIpkQxpF23zwQBD9J3Mu0LYk-2hFnn5un8jUj
pedronis@ubuntu-64:~/scratch$ snap info --verbose core_3291.snap
path: "core_3291.snap"
name: core
summary: snapd runtime environment
notes:
confinement: strict
broken: false
version: 16-2.29~rc1
type: core
sha3-384: ErgE1H1xkfTdWHtguHfHmItnaPYlIpkQxpF23zwQBD9J3Mu0LYk-2hFnn5un8jUjit’s a url-safe base64 encoding of the SHA3-384 hash of the file
What should I do at this point?
as I said not sure why your core should be corrupted, we check its hash before starting using it at least. so it was corrupted later than when it was refreshed (in theory).
can you download as I did core again and find out if the size is the same? how different/corrupted it is?
do you have (other) filesystem problems?
Fetching snap "core"
core Fetching assertions for "core"
alan@hal:~$ grep snap-sha3-384 core_3291.assert
snap-sha3-384: ErgE1H1xkfTdWHtguHfHmItnaPYlIpkQxpF23zwQBD9J3Mu0LYk-2hFnn5un8jUj
alan@hal:~$ snap info --verbose core_3291.snap
path: "core_3291.snap"
name: core
summary: snapd runtime environment
notes:
confinement: strict
broken: false
version: 16-2.29~rc1
type: core
sha3-384: ErgE1H1xkfTdWHtguHfHmItnaPYlIpkQxpF23zwQBD9J3Mu0LYk-2hFnn5un8jUj
No other problems I know about. As I said, I was using snapcraft fine earlier in the day yesterday, then did some updates via apt, rebooted in the evening and it stopped working at that point. Speculating that may be related as I don’t reboot often - this was 12 days uptime.
For now I have switched to the candidate channel and I’m back working.
Curious timing. I was just discussing this last week in another error. Have a look at snapcraft#1641.
Alan was kind enough to make the snap file with the incorrect hash available to me. I did a quick check:
$ hexdump -C core_3291.snap > good
$ hexdump -C core_3291.snap.popey > bad
$ diff -u bad good
--- bad 2017-10-26 14:45:22.381848717 +0200
+++ good 2017-10-26 14:45:03.081945939 +0200
@@ -927742,7 +927742,7 @@
00e27fd0 95 f3 b3 8a b2 fb 39 87 4c 1b bf 79 91 53 f7 17 |......9.L..y.S..|
00e27fe0 76 b0 02 a8 6c 13 56 1d 61 fe d1 ca 19 95 d9 96 |v...l.V.a.......|
00e27ff0 3a 23 87 85 f6 b4 3f 1d e1 cf a0 26 df 6d 09 3e |:#....?....&.m.>|
-00e28000 18 17 10 00 6b 6b 29 42 09 a0 f0 17 c6 fc 4d 98 |....kk)B......M.|
+00e28000 bd ff 9b a0 6b 6b 29 42 09 a0 f0 17 c6 fc 4d 98 |....kk)B......M.|
00e28010 03 0d 8e 36 12 2a e5 cd e0 fd 76 6a 31 c7 74 99 |...6.*....vj1.t.|
00e28020 91 7f 4f ea b1 c7 5d 4a 3b 6b b5 2f 43 98 2e 67 |..O...]J;k./C..g|
00e28030 aa 01 9a 93 3b 3c 1d a0 f2 2e c5 6f 6a d2 c9 35 |....;<.....oj..5|
and as you can see there is a difference of 4 bytes (32bit) in the file. I suspect there is some disk/memory corruption here. However this should be very rare - so if more people are affected it could be something else.
2 Likes
That leads to the question of why it was able to install a core which was ‘broken’ and didn’t roll back or produce an error? if the sha3sum is wrong, why did the core get used?
as we said we do check the hash (actually more than once) during install/refresh, so the file got corrupted later, or there was some kind of memory vs disk content issue during install. Or yet a completely different kind of issue we are not seeing yet.
Oh, I misunderstood. I thought it might have been corrupted during download. Gotcha!
@pedronis isn’t this something we should check every time the snap is mounted (e.g. at boot)?
2 Likes