I want to use classic confinement for my snap, but I’m having some issues in the ‘override-pull’ stage. In order to check that the problem is not caused because of my snapcraft.yaml, I’m following this tutorial to try to replicate the error.
If I execute it in my Ubuntu Trusty machine, it fails with the next message:
Pulling asciinema
Segmentation fault (core dumped)
Failed to run 'override-pull': Exit code was 139.
Name Version Rev Tracking Developer Notes
core 16-2.32.6 4571 stable canonical core
snapcraft 2.42 1500 stable canonical classic
On the other hand, if I execute it on a Ubuntu Xenial, I can compile it successfully. The same snap versions as in the Trusty machine are installed, regarding the machine configuration:
I tried to find some information about the error and I just found this, but in this case the author of the thread points that locally he can build the snap.
Answering to your question, I just want to use snap as a packaging tool for my indigo workspace, for now, isolating is not a hard requirement. I know I could build the snap using the snap confinement on a xenial machine, however, if I did so the compilation would fail as some trusty armhf specific libraries are required at that time.
I’ve just tested it. Unfortunately I’m getting the same error (Failed to run 'override-pull': Exit code was 139.) I also tested it with other snapcraft.yaml experiencing the same behaviour.
Name Version Rev Tracking Developer Notes
core 16-2.32.8 4650 stable canonical core
snapcraft 2.42.1 1594 edge/… canonical classic
Hi @kyrofa, I was taking again a look to this and I’m confused. Were you suggesting me to test the PR #2128 using snapcraft-pr?
Last day I didn’t understand so, because of that, today I tried to test it using that tool but couldn’t manage to get it running for some dependencies errors when executing snapcraft-pr.init 2128 . When will this PR request land into any of the snapcraft channels?
Sorry for the delay @mbeneto, I’m sorry to say that I somehow missed your response.
No, I was suggesting you test the snap as given in the PR description (using the snap), which you did. However, I didn’t realize that the channel had already been closed, which means you magically got edge instead, which is of course still broken (it seems rather unfriendly that you can still install from closed channels ). Indeed, I suspect snapcraft-pr won’t work on Trusty, either.
This work stalled for a bit since we decided to solve building on Trusty via build VMs instead of the route given in the PR. We expect the ETA for that to land is still several weeks, I’m afraid.
I’m curious: can you explain why you’ve settled on classic confinement as opposed to strict? That works better on Trusty, and is something you can do today.
Thanks for your reply @kyrofa! Good to know that I was testing it as expected.
Regarding the decision of using “classic” confinement, that’s basically because of the hardware we are using. Our robot uses an in-house NVIDIA TK1 running on the top a L4T based on Ubuntu Trusty with a custom kernel, using CUDA and its own modified OpenCV libraries. Our options are really limited.
We managed to create a snap containing the whole ROS workspace, including the necessary modified OpenCV libraries and successfully compiling against them. The problem comes when we try to launch the snap, as it seems that supporting CUDA in a snap is not that easy task. I found some posts on the topic, specifically this one.
Considering what you indicate there and that we are mainly interested in snap for the automated updates, rollbacks, channels and so on, but not that much in the confinement/isolation, we thought that giving it a try in “classic” could be a fast and clean way of solving our problem. Are we on the right track?
Ah yes, I remember that now. @zyga-snapd, any chance we’ve made some progress in that area?
I can definitely follow your reasoning. However, classic is a bit of a special beast in a number of ways, not least because it only works on classic Ubuntu, not Ubuntu Core. Any chance you’ve tried good-old devmode? That fits better as a “interfaces don’t completely cover our use-case right now” type of confinement. Would you agree that, if interfaces did cover your use-case, you’d take advantage of the extra security? If so, I’d very much like to strive toward covering your use-case.
Ah, @mbeneto@jdstrand responded to the other thread pointing out that CUDA gained some support as of snapd 2.33 (which is in the beta channel of core right now). I just tested the blender-tpaw snap on it, and it does indeed seem to work. That may help you approach strict confinement.
@mbeneto also, to help unblock you a bit, we’ve opened up the PR fixing this for Snapcraft. We’re still somewhat concerned about potential side effects here, but this way you have a channel you can experiment with. Install snapcraft from edge/classic-trusty.
Yes, actually we are doing all the development from the beginning under that confinement (basically, because strict is too strict, and classic doesn’t work…).
Of course, but for now and considering we are working on a classic Ubuntu 14.04 and that we are trying to snap the whole workspace for the first time, these security/isolation features are not a priority for us.
Also, we thought that reporting this classic confinement building failure had more sense as is something much general than the problems we are experiencing with the CUDA driver, so it was likely going to be solved faster.
Update: I ran into some own dependencies problems that I thought I had already solved. Having to compile such a big project in an armhf processor doesn’t help… I hope to have an answer tomorrow!
Thank you so much @kyrofa! To accelerate the debugging, I created a snap containing the few packages requiring CUDA. First I built them using the devmode confinement, resulting in the usual error when launching it. After that, I changed it to classic and it worked! I should give it a closer look tomorrow, but looking good.
Hi @kyrofa. The channel seems closed after 30 days without any update, could you please open it again? On the other hand, will this bug be solved in the 2.43 version? Thanks!
). Indeed, I suspect 
