Linux AppImage install error

• Apr 8, 2016 - 08:35

The video "MuseScore - how to run the Linux AppImage" //youtu.be/btmK0Cg1DJs was made by one of the developers, so I followed the instructions.
On LinuxMint17.3 I downloaded and saved in home/ludo/bin/ and did:
chmod u+x there, but get this error:
/tmp/.mount_GiIRok/AppRun: line 23: /tmp/.mount_GiIRok/bin/mscore-portable: No such process

I still have version 2.0.2 installed also btw, which works fine.

Comments

• Apr 9, 2016 - 06:05

This is a very unusual error. Note that when you execute an app image, the contents of it will appear in tmp directory. I'm having trouble figuring out why AppRun does appear in the tmp dir, but mscore-portable is not found. I'm wondering if it is possible that you had a low amount of free RAM, in which case the tmp directory exceeded its maximum storage capacity after extracting AppRun, but before extracting mscore-portable. What is the output of typing "free -h" into the terminal? If you free up RAM, are you able to then run it? Might be a bug with appimages.

Reply

• Apr 9, 2016 - 08:09

free -h
total used free shared buffers cached
Mem: 7,5G 7,2G 281M 336M 615M 3,2G
-/+ buffers/cache: 3,4G 4,1G
Swap: 7,7G 288K 7,7G

When I repeated the command just now, I had the same sort of error, but in detail it's different:
MuseScore-2.0.3-x86_64.AppImage
/tmp/.mount_fH81Ra/AppRun: line 23: /tmp/.mount_fH81Ra/bin/mscore-portable: No such process

Reply

• Apr 9, 2016 - 20:28

hmm...so only have 281M free out of 7.5G total memory, which is relatively low, but that still should be enough to extract and run musescore.

I was trying to simulate a low-memory environment on my system using

stress --vm-bytes $(awk '/MemFree/{printf "%d\n", $2 * .999;}' < /proc/meminfo)k --vm-keep -m 1

but I can't seem to replicate the your error...all I can mange to do is to get musescore to basically hang on after displaying popup window.

Probonopd probably has a better idea about your error.

Reply

• Apr 9, 2016 - 19:57

I am running MuseScore-2.0.3-x86_64.AppImage without any obvious issues on linuxmint-17.3-cinnamon-64bit.iso - just downloaded the Linux Mint 17.3 Rosa Live ISO, and the current MuseScore release.

Are you using the exact same combination? Also running 64-bit?

Reply

• Apr 9, 2016 - 21:23

Affirmative. Exactly that:
Mint 17.3 rosa
x86_64 Linux 3.19.0-32-generic
Cinnamon 2.8.8
edit: and indeed 64-bit - as you can see, the kernel is upgraded vs regular 17.3Rosa - don't know if that could matter.

Reply

• Apr 9, 2016 - 21:40

(@probono - glad to see you on here too! Hope you like the video!)

@LazyLew, your problem seems very strange to me. It's probably a low-memory issue as @ericfont suggested. Can you try running the AppImage from the command line with some different options, just to see if they work? You'll need to "cd" to wherever you saved the AppImage first.

./MuseScore*.AppImage  --help
./MuseScore*.AppImage  man  # press "Q" to quit - but not just yet!

If the "man" command is successful then leave the manual page open in the terminal while you open a new terminal window and run these commands:

ls -l /temp/.mount_*/
ls -l /temp/.mount_*/bin

Please include the output of the "ls" commands in your reply. If you don't run the "ls" commands (because "man" didn't work) then please include the error you got with "man". If the output is very long (more than 20 lines or so) then paste it into a .txt file and add that to your post as a file attachment instead of pasting the text straight in the reply box.

Reply

• Apr 9, 2016 - 22:16

ludo@ludo-desktop ~/bin $ ./MuseScore-2.0.3-x86_64.AppImage --help
/tmp/.mount_o5L9aB/AppRun: line 20: /tmp/.mount_o5L9aB/bin/portable-utils: No such process
ludo@ludo-desktop ~/bin $ ./MuseScore-2.0.3-x86_64.AppImage man
/tmp/.mount_TwWaJV/AppRun: line 20: /tmp/.mount_TwWaJV/bin/portable-utils: No such process

And about low memory - I know nothing about hardware and am not a very technical person, but do think my computer is not an old dog but pretty recent and decent.

I don't even know what this (following info) means, but it may tell you something about my system and memory?
CPU: Intel Core i5-3470T CPU @ 3.6GHz
RAM: 4258MB / 7668MB

Reply

• Apr 9, 2016 - 22:32

Indeed! You have a Core i5 processor and 8GB of RAM - should be plenty good enough! You might want to try installing the AppImage on a LiveISO copy like probono suggested.

But the problem gets even weirder! It seems the AppRun bash script is being extracted successfully but nothing else is, not even bin/portable-utils, which is only another bash script!

@probono, any idea what could be going on? Here's the line in AppRun. Is AppRun stored separately in the ISO header as well as within the ISO?

Reply

• Apr 9, 2016 - 22:41

I don't think the file completed download.

@Lew, can you let me know the size of your download? (You can right click the file and look in properties/)

@probonopd & shoogle, I can replicate the error by just copying the first 1MB of the AppImage:

[e@m4500 ~]$ dd if=MuseScore-2.0.3-x86_64.AppImage of=partial bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00511804 s, 205 MB/s
[e@m4500 ~]$ chmod +x partial 
[e@m4500 ~]$ ./partial 
/tmp/.mount_Ehm13n/AppRun: line 23: /tmp/.mount_Ehm13n/bin/mscore-portable: No such file or directory

I think maybe AppImages should do some checksum check on first run...

Reply

• Apr 9, 2016 - 22:52

@Lew, could you check those digits ordering...the size in my filemanager says it is 71.6MB (not 76.1MB)

I'm wondering if the file is corrupted...as in the total number of bits is correct, but the bits are incorrect. Can you report the results of the following command:

md5sum MuseScore-2.0.3-x86_64.AppImage

Reply

• Apr 9, 2016 - 23:27

@ericfontainejazz, AppImages can't test their own checksum:

1. You don't know the checksum until after you have created the AppImage.
2. A malicious AppImage could just print "checksums match!" without doing any tests.

I suppose you could get around (1) by pulling the expected checksum from the web, or by only testing the checksums of the files inside the AppImage and not the AppImage itself. There's no way around (2) unless the test is done by some kind of AppImageManager program that is separate to the AppImage, but how would it know what the checksum should be? Anyway, file corruptions on download are extremely rare.

Reply

• Apr 9, 2016 - 23:38

I didn't consider #1. Good point.

regarding #2, I wasn't suggesting for security reasons. I was only suggesting for file download or storage corruption reasons. But I suppose those integrity issues should be the concerns of the download program and the filesystem, respectively.

Reply

• Apr 10, 2016 - 08:44

@Lew, does that error happen with a larger AppImage, such as OpenOffice (250MB)? https://bintray.com/artifact/download/probono/AppImages/LibreOffice-5.0…

@shoogle/probono, I believe that "Could not cd into usr" line corresponds to this line:
https://github.com/probonopd/AppImageKit/blob/master/AppRun.c#L135
So I'm guessing the probono AppImages use AppRun.c, while shoogle's MuseScore uses his bash version... But seems same sort of thing is happening...

Reply

• Apr 10, 2016 - 09:58

Thanks. I'm at a bit of a loss to explain what is going on. I can't think of what to try next...maybe in a few hours Shoogle or probono will suggest something.

@shoogle/probono, since same error happens with <1MB AppImage and with 250MB AppImage, and since user has plenty of RAM, I'm now inclined to reject my first theory of limited memory.

Looking at AppRun.c, that error message occurs after succesfully reading a filename of somename.desktop from the root of the tmp .mount dir, and reading a line beginning with "Exec=" from that file, but then is not able to cd into the usr directory. Could the error lies somehow in xorriso extraction? What reason could explain why a regular file.desktop could be extracted, while a folder could not being extracted?

Reply

• Apr 10, 2016 - 11:36

LazyLew, that is very strange, I never encountered such an error. Thanks for reporting!

Please do the following steps:

First try

Run the Leafpad AppImage, then type "mount" into a terminal to find out the mountpoint of Leafpad (while Leafpad is running), then create a .tar.bz2 archive of the mountpoint and upload it somewhere for analysis.

Second try

Close any running leafpad. Loop-mount the Leafpad AppImage (sudo mount -o loop path/to/AppImage /mnt) and then try to run /mnt/AppRun - does it run?

(Sorry I can't explain the steps in every detail at the moment since I am away from the computer; maybe someone else can assist to write down the precise steps).

Reply

Do you still have an unanswered question? Please log in first to post your question.