Copy snap "core" data (cannot copy "/var/snap/core/2774" to "/var/snap/core/2774": failed to copy all: "cp: cannot stat '/var/snap/core/2774': No such file or directory" (1))
@chipaca says it’s triggering a known snapd bug which has been fixed in master, but possibly snapcraft is doing something it shouldn’t.
I’m starting snapcraft with SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft. lxd is configured and working fine via lxd init --auto I have had snapcraft build successfully previously, with exactly the same setup on this machine, but for some reason it has decided to stop working.
snap version on my host:
snap 2.27.5
snapd 2.27.5
series 16
ubuntu 17.04
kernel 4.10.0-33-generic
and in the container:
snap 2.27.5
snapd 2.27.5
series 16
ubuntu 16.04
kernel 4.10.0-33-generic
it appears to be brute-forcing the snapd installation from an offline .snap file:
subprocess.CalledProcessError: Command '['lxc', 'exec', 'local:snapcraft-mars', '--', 'snap', 'install', '/run/core_2774.snap']' returned non-zero exit status 1.
So it’s failing having downloaded core_2774.snap directly rather than via refresh or install and then doing an installation via snap install /run/core_2774.snap from the now offline file.
If it doesn’t clean up the file when it fails in the manner above, then the file hasn’t actually been downloaded because it is currently non-existent at that path. (probably a misnomer, actually, because it shuts the container down after it runs and /run is a tmpfs)
For snapcraft to check beforehand if the version is the same is more error-prone than leaving that to snapd which does it anyway. Worst case a smallish file is copied and ignored.
This is reliably reproducible on my system. Simply:
remove any pre-existing lxd container from previous builds
run new build: SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
RE-run the command and notice that it worked the first time but failed the second
This is specific to re-using the same container multiple times, I believe. Something is being left in a wonky state the second time the container is booted.
This regardless of triggering a snapd bug, should be fixed on our side to not install if the version we want is already there (snaps with assertions will allow for proper checks).