Segfault when running Arch image on Ubuntu 20.04
hwittenborn opened this issue · 6 comments
I'm attempting to package up an application using the Arch image, but attempting to use that on an Ubuntu 20.04 host system is resulting in a segfault.
I'm assuming the images are supposed to be runnable on any system, right? I'm thinking the Arch image might only be able to be run on Arch system, but afaik I just install stuff into the container and then distribute the arch.fim file (after I rename it and such).
Strangely I'm having the issue with the alpine and focal images as well. I'm running Ubuntu 20.04 in a VM if it helps, I'm not quite sure what might be going on outside of that though.
Hi @hwittenborn, thanks for the bug report! Yes they are supposed to work on any linux distribution, I just tested the arch image in a new ubuntu 20.04.6 VM to make a firefox package and had no issues. Does running FIM_DEBUG=1 ./my-app.fim generates any output? Also, is the image that is failing compressed?
Other cause of this issue could be that your /tmp/ mountpoint has no space left for writing. I've come across this issue in arch, which limits tmpfs by default to around 4G. You can check this with:
df -h | grep -Ei "/tmp|Filesystem"
You can increase the /tmp available space with:
sudo mount -o remount,size=16G,noatime /tmp
I'm not quite sure what happened, but I spun up a new VM last night (and hadn't done anything with it until now), and the images appear to be working fine in that now.
I'm not quite sure what might've been going on previously, but I know that when it wasn't working previously that it'd wait a second before segfaulting the first time I ran the image, and then it'd segfault immediately. I'm thinking that might be caused by /tmp getting filled or something, but I wouldn't know much else now that everything working.
This is good for me to get closed though, thanks for the pointers as to what might be going on regardless! Feel free to reach out if you want any info on anything.
When you reboot the computer it clears the contents of the /tmp directory, which probably solved the issue of insufficient space for the compression step. I'll change the temporary folder location for this in a future release, to avoid this issue. :)
Now on 3f50f37 the compression directory is created where the .fim file is located.