Appimagekit: Latest appimaged-*.AppImage fails with: `libz.so.1: cannot open shared object file`

[KurtPfeifle]

This happened on Debian Stretch, with a download from 5 minutes ago from your official "continuous" release channel:

kp@stretch:~> ./appimaged-x86_64.AppImage --appimage-version
   /home/kp/AppImages/appimaged-x86_64.AppImage: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

kp@stretch:~>./appimaged-x86_64.AppImage --appimage-help
   /home/kp/AppImages/appimaged-x86_64.AppImage: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

[TheAssassin]

zlib is one of the most common ever libraries. Therefore, it is listed in the excludelist.

Could you provide some additional information? What image of stretch did you use?

[KurtPfeifle]

Hey, all the previous AppImages (unless they had a bug, which I reported then, like this one) worked on this system. And I haven't run an update or upgrade of the system...

[KurtPfeifle]

kp@stretch:AppImages> ls -l /lib/x86_64-linux-gnu/libz.so.1*
lrwxrwxrwx 1 root root     13 Jan 29  2017 /lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.8
-rw-r--r-- 1 root root 105088 Jan 29  2017 /lib/x86_64-linux-gnu/libz.so.1.2.8

[KurtPfeifle]

It's not "an image of stretch", it's a Debian, once installed as Jessie, dist-upgraded to Stretch:

kp@stretch:AppImages> cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[TheAssassin]

I asked for a link to the image to be able to attempt reproducing this issue. The different images highly differ from each other.

[KurtPfeifle]

The only thing that changed was the version of appimaged-x86_64.AppImage, which I downloaded to replace the previous one 5 minutes before reporting this issue...

[KurtPfeifle]

I don't know how else I could convince you that all evidence points to the most recent appimaged-x86_64.AppImage being at fault:

kp@stretch:AppImages> ./appimaged-x86_64.AppImage --appimage-version
./appimaged-x86_64.AppImage: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

kp@stretch:AppImages> ./appimagetool-x86_64.AppImage --appimage-version
Version: continuous-7-g4edf2e5

kp@stretch:AppImages> ls -l appimage*AppImage
-rwxr-xr-x 1 kp kp  232356 Nov 23 11:43 appimaged-x86_64.AppImage
-rwxr-xr-x 1 kp kp  431800 Nov 23 11:18 appimagetool-x86_64.AppImage
-rwxr-xr-x 1 kp kp 7505592 Nov 21 23:24 appimageupdatetool-165-1c08c2b-x86_64.AppImage
-rwxr-xr-x 1 kp kp 7429112 Nov  7 20:43 appimageupdatetool-x86_64.AppImage

[TheAssassin]

The problem is I can not make any guess what is going on here. I can only tell that it works fine locally. Remote debugging isn't possible via GitHub issues. Maybe we should move this conversation to the IRC channel.

[KurtPfeifle]

So you are saying this works on all the systems you tested ?!?

And that the ./appimagetool-x86_64.AppImage --appimage-version command I tested (on the same system, in the same minute) does not need to open libz.so.1?

[TheAssassin]

Short version: yes.

Long version: Tried on my Ubuntu 16.04.3 LTS, the latest Debian stretch Docker container, and the latest openSUSE and Fedora containers.

Since you are apparently unwilling to give more information about what system you run exactly (and yes, the link to the ISO you used to install your computer with would probably help), I am closing this issue, being unable to reproduce it. I could only debug this properly if I had hands on your computer. If you find a way to reproduce this (e.g., download a fresh copy of the stretch ISO, run it in a VM, and reproduce the issue, which is what I was about to try), feel free to reopen.

[KurtPfeifle]

So I have 3 different versions of appimaged-AppImages here. I re-named the most recent one accordingly, and I downloaded another one which isn't tagged 'continuous' but appears on your release page under the label 10 (even though its version also reports something 'continuous'):

kp@stretch:AppImages> ls -ltra appimaged*
-rwxr-xr-x 1 kp kp 244728 Nov  9 20:29 appimaged-x86_64.AppImage
-rwxr-xr-x 1 kp kp 245496 Nov 19 21:54 appimaged-x86_64.AppImage.funzt
-rwxr-xr-x 1 kp kp 232356 Nov 23 11:43 appimaged-x86_64.AppImage-continuous-b0rken

Clearly, today's one doesn't work, the others do:

kp@stretch:AppImages> ./appimaged-x86_64.AppImage --appimage-version
  Version: continuous-1-g6f3138f

kp@stretch:AppImages> ./appimaged-x86_64.AppImage.funzt --appimage-version
  Version: continuous-5-g9101ceb

kp@stretch:AppImages> ./appimaged-x86_64.AppImage-continuous-b0rken --appimage-version
  ./appimaged-x86_64.AppImage-continuous-b0rken: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Maybe YOU should try on your local system again, and double-check if you was testing the right version?

[KurtPfeifle]

@TheAssassin stated:

"Since you are apparently unwilling to give more information about what system you run exactly"

Rubbish!

I gave it above. What else do you need?

It rather seems that YOU...

• are unwilling to tell in detail what information you want;
• are unwilling to investigate a clear bug.

[TheAssassin]

Dear @KurtPfeifle,

I tried to reproduce this issue in the meantime with some Debian stretch ISO in a VM and a few more Docker containers, and still can not find a configuration where the issue occurs. I guess we need to debug this hands-on, unless @probonopd has an idea how to continue remote debugging.

Sorry for being a bit harsh with my words, I did not intend to offend you (reading it a second time, I need to say I shouldn't have used "unwilling" in favor of "unable"... it was late already, and is even later right now, which is of course not an excuse).

"Since you are apparently unwilling to give more information about what system you run exactly"
Rubbish!

Continuation of this quote is:

(and yes, the link to the ISO you used to install your computer with would probably help)

Which is what I asked for, as a "fresh" installation does not yield the bug. I was hoping for finding out whether some external repositories etc. might be the cause by making sure that it works on the same image you installed your computer with (as mentioned before, it works in a Docker container).

The reason to close the issue was that I cannot think of any more scenarios to test for the bug with, I tried the ones I could come up with. I suppose it might be an issue with some external repository you use etc. (they're pretty much free to push any packet they want, Debian's apt doesn't filter). Hence, I concluded this was a very specific bug which occurs on your machine only. There's 100s of reasons why this could happen.

You also need to understand that remote debugging is quite some effort, and without yielding results, there's a point when you can't help people over the GitHub issue tracker. I've tested > 10 different OS configurations, which took me way more than an hour already. And all this was just guessing blindly, I didn't really expect success. Furthermore, I didn't see any signs you verified the bug occurs on other machines (or VMs or containers), even after telling you that I can't reproduce it on 4 different configurations, or asking you explicitly to attempt to reproduce the issue on another computer.

As I wrote on the IRC channel, you're happily invited to join us at the AIPP with your notebook, where it will be easier to debug this issue.

I'm reopening this issue for now, and will leave closing it to someone else.

[TheAssassin]

P.S.:

It rather seems that YOU...
[...]

• are unwilling to investigate a clear bug.

That claim is pretty offending. Especially since I clearly explained what I tried already, and invested quite some amount of time in debugging this, which is probably more than was required for most other bug reports, as this one _is_ pretty specific.

It doesn't mean anyone is unwilling to investigate a bug, it is more of being unable to invest further time. And time's valuable in free software projects.

[TheAssassin]

P.P.S.:

   /home/kp/AppImages/appimaged-x86_64.AppImage: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

This doesn't have anything to do with the parameters for the application, it is generated by the system's linker, which is trying to resolve dependencies on shared libraries. Hence, as soon as the application shows any other output, it means the bug did not occur.

[probonopd]

Guys, pleeease. Please run:

export LD_DEBUG=libs
sudo ./appimaged-x86_64.AppImage.funzt 2>&1 | grep libz > funzt.log
sudo ./appimaged-x86_64.AppImage.b0rken 2>&1 | grep libz > b0rken.log

and attach the logs here. Thanks!

[KurtPfeifle]

Now I slept over this affair a bit.
So let's see, how this issue was handled by A Maintainer.

---

First, a timeline (all times in GMT+1, which translate to "late in the evening, roughly spanning from 21:36 to 23:21 h" in my timezone):

09:36 PM: Reporter -- opens issue.
_{(His intention was to get it checked quickly, and to have a faulty AppImage pulled from further distribution by its maintainers, and have it pulled fast in case it really could be reproduced. To him it was a very obviously faulty new packages, as the previous version still kept working on his system throughout. "Occam's Razor", anyone?)}

10:22 PM: Maintainer -- first response. Hints that libz.so.1 is part of all systems. Request for "some" additional information. No real specifics asked.
_{(Asking for exact installation "image of Debian Stretch" is beyond bordering to ridiculous already... WTF? All previous AppImages did work on that same system in the weeks before, and now THAT system should be causing the problem?? And not the very fresh new release of a proven software release by packagers who are the real experts in this package, yet with a brand-new hot feature? Read and understand about Occam's razor first, before jumping to such conclusions. Oh, wait: Maintainer probably was not serious.)}

10:45 - 10:46 PM: Reporter -- supplies additional info as requested.
_{(Info included exact version of Debian Stretch and existence, size, location + date of local libz.so.1.2.8 file.)}

10:47 PM: Maintainer -- second response. Repeating request for "link to image".
_{(Reporter does not remember exactly when and exactly from which ISO image he installed Debian. However, even IF he knew, he would still have felt being made ridiculous by such a question when debugging the problem in case.)}

10:50 PM: Reporter -- hints (again) at fact that previous AppImages worked on that system.
_{(What else to say? Hmmm... still thinking of more.)}

10:55 PM: Reporter -- gives evidence that previous AppImages continue to work, but the one in question doesn't.
_{(What else to say? Hmmm... still thinking of more.)}

10:59 PM: Maintainer activity.
_{(Maintainer add labels to the issue: "bug", "needs verification" and "question".)}

10:59 PM: Maintainer -- says it works for him locally. Wants to move discussion to IRC.
_{(Why IRC? Isn't it better to keep all info concerning this issue at one place?)}

11:11 PM: Reporter -- asks for confirmation if release was tested on several systems.
_{(Is obviously confused by situation and by the gameplaying of Maintainer.)}

11:21 PM: Maintainer -- for first time explicitly states that release has tested alright on several systems.
_{(He accuses reporter to be "unwilling to give more information about what system [he] runs". Christ!
Indicates his own debugging means are exhausted unless he could get "[his] hands on [the reporter's] computer". Jeee-sus!)}

11:21 PM: Maintainer -- closes issue (mere 22 minutes after labelling it as "bug" and "needs verification").
_{(Yessss -- what else could one do, huh? At this point in time the Reporter already had a few more ideas of his own about what could be done to further debug this WITHOUT a days-long mission to "download a fresh copy of the stretch ISO, run it in a VM, and reproduce the issue". Boy, I'm not THAT stupid to play this game with you... Go find another victim!)}

11:28 PM: Reporter -- shows that other AppImage versions (including their file sizes) of same application DO run on his system. Asks for double-check, if Maintainer tested the same one as reported as faulty?
_{(Reporter already silently wonders, why today's filesize is around 13 kByte smaller than all previous ones? Hopes, Maintainer will have a look and complain if it does not look right. Also silently hopes for Maintainer to request MD5 sum or similar simple test for proof or disproof of version identity. STRONGLY hopes that Maintainer only is having a bad day. After all, clever Maintainer had already on another occasion quite arrogantly claimed the Reporter's debugging skillz were lacking and not "constructive" or "productive".)}

11:31 PM: Reporter (only just having seen Maintainer's accusation from 11:21 PM -- a.k.a. "unwilling to give more info" -- and his extremely fast closing of issue) says "Rubbish!"
_{(And now he finally sees that this fine young man is trying to play games with an Old Fart being his easy prey....)}

11:38 PM Reporter downloads one more time the file in question. That one works.
_{(He draws a quick obvious conclusion, takes one appropriate measure, but does not (yet) report the fact. He is tired of the game, wants to sleep and see later, how and if to report this. After all, the issue is now no more, is closed and no longer an pressing problem -- neither for him nor for other users...)}

---

I'm old. I'm slow. I'm stupid. But I'm not THAT stupid. You cannot fool me for sooo long.

Even if I'm not a developer, I can also investigate a few things. So now I'll present a few more ideas how this could have been debugged for real, had there been no childish gameplay going on. Maybe this will help future users and newcomers should they encounter similar problems:

• It works for This Maintainer on several systems?!?
  
  
  
  • So why not ask the reporter for an MD5 or SHA256 sum of the AppImage? Why ask for a "link to his Debian Stretch ISO image" instead?
  
  
  • If the MD5 sums deviate from the Maintainer's version, why not then ask the Reporter to simply download one more time and checksum+test it again?
  
  
  • If it works with new download: maybe check for...
    
    
    
    
    
    • ...caching proxies in the download chain, or for
    
    
    
    • ...general network hickups causing a Bit to toggle or a download to abort, or for
    
    
    
    • ...GitHub problems with quickly succeeding releases, or for
    
    
    
    • ...manipulations in the repository, or for
    
    
    
    • ..."natural" changes that may happen in the release pipeline, such as pulled releases by a fellow maintainer, replacing a faulty file and making everybody happy again???
    
    
    
  
  
  • If it does NOT work with new download: maybe ask the reporter for a copy of the file in question (after all, it is only ~240kB in size)?
  
  
• The Maintainer is REALLY interested to find out what is the cause of the seen and reported malfunction?!?
  
  
  
  • Why then not ask the Reporter to extract the faulty AppImage into an AppDir and have a closer look at its contents?
  
  
  • Why not extract a copy of the malfunctioning AppImage himself and see what's wrong with it? He surely is better equipped to do so than the Reporter.
  
  
  • Why not inquire with his fellow maintainers if they changed/fixed/corrected something with the download after THEY found a problem with it?
  
  
  • Why attempting to paint it as the Reporter's fault and trying to make him feel bad or ridiculed?
  
  

So, there were quite a few more options and paths to follow in order to debug this. There was no good reason to claim the need to install dozens of different systems in docker containers or VMs for testing. There were simpler options to exhaust first.

The Reporter thinks that the Maintainer in reality is quite a clever guy. He knows all this. His hacker + developers skills are superior to the Reporter's. Otherwise, he'd not be up to his task. But he tried to play games. And found a temporary victim.

But, as we say in German: "Verarschen kann ich mich auch selber!"

Because I also found out :

• The download from that same link changed the file content AFTER I reported the issue:
  
  
  
  • I reported the issue concerning file appimaged-x86_64.AppImage at 09:36 PM GMT+1 (that's 21:36 h my local time).
  
  
  • I downloaded (via wget -- which preserves modification timestamps of files) that file in question about 5 minutes earlier, so that's around 09:31 PM GMT+1 (that's 21:31 h my local time)
  
  
  • I do not anymore possess that original buggy file (which could have different modification timestamp than 09:31 PM GMT+1 (that's 21:31 h my local time), because it was overwritten in a later download, while I was trying to verify the issue I reported.
  
  
  • I DO however have another downloaded file, which...
    
    
    
    
    
    • has a ctime of 11:21 PM GMT+1, that's 23:21 h in my local time, indicating its download time
    
    
    
  
  
  • has a MD5 sum of e7644fcaf49c26857d916c837a87d94a
    
    
    
    
    
    • has a modification time-stamp of 11:43 AM GMT+1 (that's is 11:43 h in my local time), indicating its creation time on GitHub
    
    
    
    • has a file-size of 232.356 Bytes
    
    
    
    • has the same "un"-functionality as original download: "libz.so.1: cannot open shared object file: No such file or directory"
    
    
    
  
  
  • The current "continuous" channel for the AppImage in question...
    
    
    
    
    
    • has delivered to me a file with ctime of 11:38 AM GMT+1 (that's 23:38 h my time)
    
    
    
    • has an MD5 sum of e85f5a185d8c93eb80c66c2e3eae19b6
    
    
    
    • has a modification time-stamp of 11:18 AM GMT+1 (that's is 11:18 h my local time)
    
    
    
    • has a file-size of 247.480 Bytes
    
    
    
    • has a fully working condition
    
    
    
    • has a GitHub release time stamp of 11:14 AM GMT+1 (that's is 11:14 h my local time).
    
    
    
  
  

I conclude that Someone has switched the GitHub 'continuous' release channel WHILE our back and forth was going on. Switched it...

• ...from delivering a later+defect file release (delivering a file 'mod-time'-stamped as 11:43 AM GMT+1) which I downloaded at 23:21 h my time (or 11:21 AM GMT+1)
• ...to deliver an earlier+working file release (delivering a file 'mod-time'-stamped as 11:18 AM GMT+1) which I downloaded at 23:38 h my time (or 11:38 AM GMT+1)

...without telling me. And that switch must have happened after 23:21 h (closing of issue) and before 23:38 h.