Ricardo Abreu
Ricardo Abreu
I think I had come across this as well.
> No, and no. Software changes as do requirements. I guess we wouldn't need a hard guarantee that it won't change, just that it wouldn't change silently along a version...
Those are great finds @sharder996! We should refuse anything below what they point out there in both GUI and the daemon, IMO. And we should probably link to that from...
Hi @nicolasbock, I am afraid there is no workaround at the level of Multipass yet. This is a generic snap problem that should hopefully be fixed at the snap level....
Hi @jedmundstephens, it would appear that there is a disconnect between what images Multipass thinks LXD has and the images it actually has. Hard to say why, but logs corresponding...
Hmm, OK. The image hash you posted initially is correct (I got the same one). So the Multipass daemon gets the right hash after [fetching](https://github.com/canonical/multipass/blob/b3050c24312c838ed2bd94ff2ee634828dbb14ae/src/daemon/daemon.cpp#L3144) the image, but then immediately...
OK, so there appears to be some problem getting the image into LXD. Multipass should be able to identify that better, but the main problem appears to be on LXD's...
The main issue was on LXD and that backend is now deprecated in Multipass and soon to be removed, so closing this.
You're right @louiseschmidtgen. This is indeed a limitation of the current implementation. I'd swear there was a ticket for this, but I couldn't find it, so let's keep this one....
This is still the case. I suppose we should just follow whatever `scp` does in here.