I’ve been trying to build a snap on Solus. By default, snapcraft tries to run multipass and fails with the errror launch failed: Failed to set iptables rule for table mangle: iptables: No chain/target/match by that name. If I add SNAPCRAFT_BUILD_ENVIRONMENT=host, I get an error saying Native builds aren't supported on Solus. Given snap comes prepackaged with Solus now I’m not sure why native builds wouldn’t be supported and I’m wondering how I should go about building snaps then?
1 Like
@hmnd I’ve had that issue myself.
Pretty sure I used base: core18 to bypass it. Give it a go and add it to your snapcraft.yaml file.
No luck with that, either. snapcraft init already has base: core18 as the default.
I’ve got the same problem on Solus.
Hi, thank you for trying snapcraft on Solus.
Use of SNAPCRAFT_BUILD_ENVIRONMENT is not really supported, I would appreciate if you can point me to any documentation mentioning this.
The reason --destructive-mode (building on host) will not work on Solus is that there is no matching base for Solus nor is there a way to handle build-packages or stage-packages which are in a way, tied to the base in use.
While I will need to leave sorting out the multipass issue to @Saviq, you can also try using LXD by passing --use-lxd in the CLI (consider installing and running lxd init prior).
Hey,
There’s no documentation mentioning that that env variable is supported, but that’s just one of the things I tried to get it to work.
Using LXD works, however! Thanks for your help!
Doing a search on the documentation website shows up:
It isn’t linked in the sidebar on the left, but is discoverable from https://snapcraft.io/docs/docs-roadmap. It’s also clearly out of date, claiming that Snapcraft 3.x doesn’t support LXD builds.
For what it is worth, I ended up switching my Github action from the --use-lxdcommand line argument to SNAPCRAFT_BUILD_ENVIRONMENT=lxd because it was more reliable. If you’re building an old project that doesn’t include the base: keyword, Snapcraft re-execs to the legacy version which supports the latter but not the former. Combined with cargo culting from old guides, this could cause people to favour the environment variable.
2 Likes
I was about to start a new topic with the same title but then I discovered this. 
Since the root cause was not resolved here decided to continue here.
I had the same problem building my snap, starting multipass, on Solus. When comparing the iptables setup with my Manjaro system that runs multipass just fine I noticed the following differences.
Manjaro
$ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i mpqemubr0 -p tcp -m tcp --dport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A INPUT -i mpqemubr0 -p udp -m udp --dport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A INPUT -i mpqemubr0 -p udp -m udp --dport 67 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A FORWARD -i mpqemubr0 -o mpqemubr0 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A FORWARD -s 10.94.23.0/24 -i mpqemubr0 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A FORWARD -d 10.94.23.0/24 -o mpqemubr0 -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A FORWARD -i mpqemubr0 -m comment --comment "generated for Multipass network mpqemubr0" -j REJECT --reject-with icmp-port-unreachable -A FORWARD -o mpqemubr0 -m comment --comment "generated for Multipass network mpqemubr0" -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -o mpqemubr0 -p tcp -m tcp --sport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A OUTPUT -o mpqemubr0 -p udp -m udp --sport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A OUTPUT -o mpqemubr0 -p udp -m udp --sport 67 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT
Solus
$ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i mpqemubr0 -p tcp -m tcp --dport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A INPUT -i mpqemubr0 -p udp -m udp --dport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A INPUT -i mpqemubr0 -p udp -m udp --dport 67 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A OUTPUT -o mpqemubr0 -p tcp -m tcp --sport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A OUTPUT -o mpqemubr0 -p udp -m udp --sport 53 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT -A OUTPUT -o mpqemubr0 -p udp -m udp --sport 67 -m comment --comment "generated for Multipass network mpqemubr0" -j ACCEPT
Not sure what to do with that knowledge though.
@Saviq might be able to help on this one.
May be worth filing a bug @ https://github.com/canonical/multipass/issues
HI @trixton, you’re obviously missing some FORWARD rules in there, and I’d imagine you’re actually missing more in the nat table:
$ sudo iptables-legacy -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.137.134.0/24 ! -d 10.137.134.0/24 -m comment --comment "generated for Multipass network mpqemubr0" -j MASQUERADE
-A POSTROUTING -s 10.137.134.0/24 ! -d 10.137.134.0/24 -p udp -m comment --comment "generated for Multipass network mpqemubr0" -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 10.137.134.0/24 ! -d 10.137.134.0/24 -p tcp -m comment --comment "generated for Multipass network mpqemubr0" -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 10.137.134.0/24 -d 255.255.255.255/32 -m comment --comment "generated for Multipass network mpqemubr0" -j RETURN
-A POSTROUTING -s 10.137.134.0/24 -d 224.0.0.0/24 -m comment --comment "generated for Multipass network mpqemubr0" -j RETURN
What does modinfo nf_tables say on Solus? There’s a chance they migrated to nftables already, and don’t have the transition tools in place.
2 Likes
I switched to Kubuntu, in order to make some progress with my snap.
Will test that once I get Solus reinstalled and get back to you.
Ok @Saviq, now I’m back on Solus.
$ modinfo nf_tables
filename: /lib/modules/5.6.19-159.current/kernel/net/netfilter/nf_tables.ko
alias: nfnetlink-subsys-10
author: Patrick McHardy kaber@trash.net
license: GPL
depends: nfnetlink
retpoline: Y
intree: Y
name: nf_tables
vermagic: 5.6.19-159.current SMP preempt mod_unload modversions
Hi @trixon, sorry for the late reply… again…
So yeah, you have nftables loaded, but the iptables command line still works on the legacy iptables tables. It’s customary to use the compatibility layer (iptables binaries actually speaking nftables to the kernel), but if you can’t get that going, our LXD backend should help:
$ snap install lxd
$ snap connect multipass:lxd lxd:
$ sudo multipass set local.driver=lxd
1 Like