I’m in the process of porting my gnucash-jz package to core18. When I attempt any build, snapcraft (after prompting me to install multipass) attempts to start a VM, then hangs:
Launching a VM.
start failed: timed out waiting for instance to respond
An error occurred when trying to start the instance with 'multipass': returned exit code 2.
Ensure that 'multipass' is setup correctly and try again.
Rebooting, reinstalling multipass etc. doesn’t seem to fix the problem.
Is there some way to troubleshoot this?
UPDATE: I think I isolated the problem. Multipass creates the virtual network interfaces mpqemubr0 and tap-XXXXXXXX. With firewalld installed on my machine, these were automatically assigned to the “public” zone and that apparently prevents the VM created by multipass from performing DHCP and initialising its network connection. The VM then just waits forever for the network to come up.
Manually switching these interfaces to “trusted” seems to fix it. Maybe multipass should set the correct firewall rules automatically?
Hi @jzimm glad you worked it out. The problem is there’s so many firewall solutions out there it’s impossible to deal with them all. We do set up rules for the instances, but apparently your firewall overrides those.
I think the only meaningful thing we could do is report a better error, suggesting firewall issues when we can’t reach the instance.
A better error message, or some log message ("Waiting for VM network to initialize…) would certainly help. More people will unavoidably run into this problem.
I ran into this problem earlier today and yesterday as well. I had to snapcraft clean and restart my computer to be able to build again. I have a fast internet connection and no special configuration for my network or firewall. It feels like Snapcraft sometimes waits for a failed network request and doesn’t retry or recognize that it’s dead.
In fact this also brings the question why exactly does snapcraft need to use a VM? A standardised build container, like snap cleanbuild but updated for core18, would be much more efficient.
The release notes explain it better, but the gist of why VM’s are being used is because Snapcraft is now supported on MacOS and the experience is seamless between Linux and MacOS due to the use of Multipass.
@townsend VM does not solve the problem when we want to build process to consume all system resources. Unless snap is not meant to be a solution to create reproducible build environment. In that case, we then need to maintain two build system, snap and perhaps another container solution.
If Mac is the concern, why not support docker, which works on Linux and Mac?
Also, what’s the reason to retire lxd as a build environment? It was not in the release note and on this forum anywhere.
@townsend As I see it, this causes a regression for package maintainers. With the previous approach it was very convenient to keep a “prime” directory, possibly mounted into a build container, that could be mounted as a snap through “snap try”, and work iteratively in it until all necessary adjustments were made and integrated into snapcraft.yaml. Now with multipass, builds are slow, there is no possibility to just hack and try some stuff in a half-working snap to work it out, and it generally goes backwards in terms of user friendliness.
Two comments re the Mac concern. If that’s really the motivation, couldn’t the same build environment be provided as a container for Linux systems and as a VM image on Mac? For snapcraft maintainers, doesn’t it ultimately come down to maintaining a tarball that can be extracted either in a container or on a virtual disk?
And second, I don’t know if I’m the only one who thinks this, but is it fair and reasonable to annoy Linux developers in order to facilitate support of a proprietary, closed source platform that many Linux users frankly don’t give a flick about, to put it mildly?
Hey all! I’m a Multipass dev and not a Snapcraft dev, so I’ll leave up to them to answer your questions. I was just trying to give my opinion about why the change, but it seems to have lead to more questions that I can’t answer:)
It was exactly what happened to me. I uninstalled ubuntu firewall and it solved the problem.
In addition I did some instructions from below (snapcraft clean; multipass launch; reboot) and now is working fine again
I also encountered the similar the issue when I used snapcraft to create a uc18 gadget for arm64:
$ snapcraft cleanbuild --target-arch=arm64
Setting target machine to 'arm64'
Creating snapcraft-loudly-fresh-mole
Starting snapcraft-loudly-fresh-mole
...
You need multipass installed to build snaps which use the base keyword.
Would you like to install it now? [y/N]: y
snapd is not logged in, snap install commands will use sudo
multipass (beta) 2018.12.1 from Canonical✓ installed
Channel latest/beta for multipass is closed; temporarily forwarding to beta.
Waiting for multipass...
Setting target machine to 'arm64'
Launching a VM.
launch failed: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.15.0-1030-oem/modules.dep.bin'
modprobe: FATAL: Module msr not found in directory /lib/modules/4.15.0-1030-oem
An error occurred when trying to launch the instance with 'multipass': returned exit code 2.
Ensure that 'multipass' is setup correctly and try again.
Error: not found
Stopping local:snapcraft-loudly-fresh-mole
An error occurred when trying to copy files using 'lxd': returned exit code 1
I ensure that multipass can be launched formally under the host, however, the snapcraft cleanbuild always failed to trigger the multipass/lxd.
do you mean that multipass launch works fine on the host normally?
The following messages:
launch failed: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.15.0-1030-oem/modules.dep.bin'
modprobe: FATAL: Module msr not found in directory /lib/modules/4.15.0-1030-oem
An error occurred when trying to launch the instance with 'multipass': returned exit code 2.
suggest there’s something weird going on with your kernel packages. We’re using a tweaked kvm-ok script to check whether your host can do KVM. It fails loading the msr module that allows checking for BIOS support of virtualization. Can you check if you can modprobe msr and run the upstream kvm-ok script from the cpu-checker package?
If you would also please file an issue on our GitHub we can probably make this a non-fatal error in the check script.
I’m getting this issue when trying to build a package:
$ multipass launch
One quick question before we launch … Would you like to help
the Multipass developers, by sending anonymous usage data?
This includes your operating system, which images you use,
the number of instances, their properties and how long you use them.
We’d also like to measure Multipass’s speed.
Send usage data (yes/no/Later)? no
Launched: spruce-dugong
# multipass itself is working fine
$ snapcraft
Launching a VM.
launch failed: Downloaded image hash does not match
An error occurred when trying to launch the instance with 'multipass': returned exit code 2.
Ensure that 'multipass' is setup correctly and try again.
The most annoying thing is that it redownloads the image each time so that debugging this is really painful. Are there workarounds for this issue?
I can’t even use cleanbuild instead :’(
snapcraft cleanbuild
The cleanbuild command is no longer supported when using the base keyword.
How do I directly build on the host system, nowadays?
