and still can’t find any available solution. Am I missing something out?
I’m facing a weird issue with my recent snap upload where the snap is not able to access /usr/bin/fold, which is a part of Busybox commands on amd64 Ubuntu bionic.
The answer is probably “you shouldn’t”, the resources you should access are in the Ubuntu Core, your snap, and the very limited set of things exposed from the host system.
/usr/bin/fold is provided by the coreutils package, and should be provided by the core snap at /snap/core/current/usr/bin/fold.
I’m not sure how it is implemented but it seems that you can’t directly point the script to access files under /snap/core/current/*.
You can verify it by run snap run --shell _snap_name_ and try to access these files.
I suspect that this is probably a snapcore/snapd’s bug, which doesn’t expose /snap/core/current/usr/bin/fold…, maybe it can be workarounded by adding the coreutils package to stage-packages ?
I tested the coreutils packages (and it requested libc6 package). After installing the built snap, the bashell unables to run and yield: Segmentation fault (core dumped).
Also, during build, it has a lot of warnings, like:
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmp5j99l32i’
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmphh95zh6b’
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmpi_aoun50’
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmp4t49upz6’
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmp2e8uiyal’
@chipaca, what is the proper way to do? Based on the shell inside the snap, the fold is given:
$ which fold
/usr/bin/fold
$ which echo
/bin/echo
$ which ls
/bin/ls
I wouldn’t want to alter the original software since it has no such issue.
UPDATE
Appearently, fmt works, and the location it points is:
$ which fmt
/usr/bin/fmt
Both fmt and fold originated from the same coreutils package. Why fold is not working is unknown.
the easiest thing would be to ship fold (just that binary, not the whole coreutils) in your snap.
I don’t understand what you’re doing. I don’t know much snapcraft, but I don’t think it ever pulls in libc6 unless you tell it to. It sounds like you’re building with, or shipping conflicting versions of libc6. What exactly are you doing?
I don’t know what you’re building when you see those errors, but if it’s Qt, you might be needing an upstream fix; in any case it’s not (directly) related to the tools you’re using to build.
fmt is whitelisted, so you can run it from core. fold is not, so you need to ship your own copy (or request that we add it to the whitelist, and then wait for that updated whitelist to ship).
Basically I add the stage-packages, with the snapcraft.yaml, to build fold (alongside with its siblings):
stage-packages:
- libc6
- coreutils
and rebuild it. Then when I run my app after snap install, it went into segmentation fault.
I thought of that but I strongly believe it is a workaround, especially when developing mutli-architecture software.
I believe we arrived to the source of the problem now: fold is not whitelisted. Therefore snap fails. Also, I wasn’t aware there is such a thing as well and I assume all commands listed in the BusyBox are all white-listed.
Is there a website where we can check the white-list commands? This site should be very helpful for future shell scripting inside the snap.
Unless I’m missing something where I can set /usr/bin/fold into an internal program for internal consumption. Is there a way?
The whitelist / blacklist of the commands affecting Busybox list is completely out-of-the-box and not documented. That’s the actual cause of the issues.
That’s a good help! If there is any similar scripting project that needs BusyBox commands, I’ll create a request.
there should be no need to as long as you use snapcrafts “apps” entry … this auto-generates a wrapper with a PATH entry pointing to $SNAP/bin, $SNAP/usr/bin etc etc … so “fold” should be executed from $SNAP (this indeed gets hairy if your binary usees full paths (which it shouldnt if you want to write portable code)).
in case you want more complex setups you can also take a look at the experimental layouts feature …
Yeap. If we use the apps entry, it will expose the fold as an app externally. In some situation, we might not want it. No worries, I can still live with $SNAP variables for time being.
Thanks for sharing !
passthrough is definately new and came to realize, I’m on the bleeding edge. Reading through:
That’s definitely a way but it will create extra documentation step and exhibits enough complexity for packaging process. These 2 are enough to say a packager had failed its manifesto. By ideal user experience, we should always restrict the amount of user action to 1 and only:
$ snap install <software>
The rest are packager’s job.
Thank you! Am already editing 1.3.1 release to use fmt. No hush.
One thing I think you’ve misunderstood: the commands in core are not busybox, they’re the full GNU (in the case of coreutils) toolset, from 16.04 in the case of core (18.04 in core18).
I use BusyBox command list as my checklist mainly because on some single-computer-board (arm/x86), the OS (e.g. Yocto) usually deploys BusyBox, which has limited commands. You’re right too! Those commands are from GNU coreutils on our computers (x86 amd64, i386).
To ensure bash script is working across systems, I try to maintain the bash script to use commands within the BusyBox (left alone bash has the POSIX Compliant vs. sh to deal with too).
For software that works on all available arch, yet compliance: Go binariesSnapcraft ==
Action taken: retitled again to match the context for next person search.
!
