Closed olejorgenb closed 7 years ago
Is there a Live ISO of NixOS that I could try? (I don't feel like installing it into a dedicated partition...)
Wouldn't it be possible to sudo ln -s /nix/store/kj*ihqg-glibc-2.25/lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2
or something along those lines? As long as this is not done, NixOS is not gonna be compatible with any third-party Linux applications (which I would say is the whole point of a Linux desktop operating system).
I tried linking (both lib64 and lib linkers) to root. Got further, but still errors:
Stdout: https://paste.pound-python.org/show/qxj5Ino6tg7Y0Fgu2jk0/ Stderr: "Error: Error executing 'subsurface.wrapper'; return code: -1"
(This includes fuse, in LD_LIBRARY_PATH
needed to get the actual image to run)
https://nixos.org/nixos/download.html has a livecd
This is great progress. It means the AppImage is working. :+1: (What is not working is what is inside the AppImage, in this case the subsurface.wrapper script.)
So to summarize, to get AppImage working on NixOS one must link the loader to a location where all "regular" Linux applications expect it to be. I don't think AppImage can do something about this. Apart from that, it appears to be working.
(The wrapper script is not really part of the recent AppImageKit anymore.)
And add fuse and a couple other libraries to LD_LIBRARY_PATH
I want to add a link to appimage-run script which runs AppImage executables on nixos
(Google sent me here, so the link can be useful for others).
@kevroletin perhaps NixOS could make AppImages launch through that script? Perhaps they want to collaborate with us bringing https://github.com/TheAssassin/AppImageLauncher support to NixOS, which could run that script automatically to run AppImages?
fwiw, there is a graphical live ISO of NixOS at https://nixos.org/nixos/download.html. :+1: In case someone wants to play with it.
@TheAssassin, ah, I didn't realize that:
https://github.com/trufflesuite/ganache
worked for me (now I test random images from https://bintray.com/probono/AppImages and I had no luck with 2 images)I've patched elf to change its default interpreter using these commands:
nix-shell -p binutils stdenv wget dpkg nix-index stdenv.cc
patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" ganache-1.2.2-x86_64.AppImage
Yep, bringing AppImage support would be cool, but I don't sure who can help. Maybe appimage-run
author and contributors can help or can point in the right direction? cc @tilpner @volth @joachifm I'll also ask people in the IRC.
@kevroletin Try again with appimage-run from recent master (< 4h old, right now)
@tilpner, I've checked the latest appimage-run (from Oct 25 10:38:29 2018) and it gave much better results. I've randomly (well, from the first page of https://bintray.com/probono/AppImages) downloaded several images and most of them worked (atom, azpainter, arduino-ide), and one didn't work (audacity, but it's 3 years old, maybe something has changed in a way how AppImages are produced?).
audacity, but it's 3 years old
Check those newer builds: https://github.com/probonopd/audacity/releases
Hi,
I associated AppImage files to appimage-run
(i don't know if it's relevant but i'm on KDE)
That added this file ~/.local/share/applications/appimage-run.desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Exec=appimage-run
MimeType=application/vnd.appimage;
Name=appimage-run
NoDisplay=true
Type=Application
And that added those lines to this file ~/.config/mimeapps.list
[Added Associations]
+application/vnd.appimage=appimage-run.desktop;
+application/x-iso9660-appimage=appimage-run.desktop;
# some other stuff here
[Default Applications]
+application/vnd.appimage=appimage-run.desktop;
+application/x-iso9660-appimage=appimage-run.desktop;
# some other stuff here
On other systems, something like appimage-run
is not needed. Actually it was one of the design goals of AppImage that in order to run an AppImage, you don't need to install some runtime on the host system first.
Can NixOS do without appimage-run
?
appimage-run
import many dependencies to be able to execute the AppImage
Those dependencies are not installed by default
NixOS is very minimalist by default
But we could imagine an option
that allow AppImage
Maybe something like programs.appimage.enable
and services.appimage.autoUpgrade.enable
PS: I'm a newbie with NixOS
Ah, I see, it's a meta dependency package that installs something like the equivalent of the ubuntu-deskop set of packages. In this case, the name is a little misleading, since one could think that it is AppImage specific. Thanks for the clarification.
So to summarize, to get AppImage working on NixOS one must link the loader to a location where all "regular" Linux applications expect it to be. I don't think AppImage can do something about this. Apart from that, it appears to be working.
That's not really a realistic solution, though, only a workaround; the entire premise of NixOS is that there isn't a global environment like this, and that all dependencies are explicitly linked to prevent collisions, hence the use of tools like patchelf
.
Requiring a system-global link to the loader to run AppImages on NixOS would essentially mean having to give up one of the primary guarantees of NixOS, which defeats the point of using it in the first place.
EDIT: For what it's worth, appimage-run
worked for me, at least with FreeCAD.
@volth and @reardencode have also contributed to appimage-run on NixOS maybe they can help ?
I think it's pretty well covered in here -- AppImages will not work on NixOS out of the box due to the fundamental design of the each. NixOS doesn't put any libraries in global scope, and AppImages are specifically designed to run with a bunch of very common libraries in global scope.
Fortunately, appimage-run works great for most AppImages, and it's easy enough to add additional libraries to it if future AppImages expect more dependencies in the global scope. (I had never looked into AppImages nor appimage-run until the day I submitted my one little patch to appimage-run)
Thanks @reardencode. Are you saying AppImages run well enough on NixOS now so that we can close this issue here? Thanks.
I'm sure appimage-run
will continue to need additional dependencies added from time-to-time. Overall though, AppImages do run well enough on NixOS. Only thing if anything, you might want to add a documentation mention for appimage-run
, to help users who come from other operating systems discover how to run AppImages on NixOS.
AppImages are specifically designed to run with a bunch of very common libraries in global scope
Is there a list of these common libraries
needed?
https://github.com/AppImage/AppImages/blob/master/excludelist
NixOS is very special and different to "average Joe's linux distro"...
I got error while loading shared libraries: libatk-bridge-2.0.so.0
when trying to run Beaker Browser >= 0.8.0 and I don't see libatk-bridge
on that list.
Is that list incomplete or maybe the Beaker Browser package is built incorrectly?
Probably a Beaker Browser issue. You might want to file an issue there. Feel free to highlight me, I'll have a look.
https://github.com/beakerbrowser/beaker/issues/796#issuecomment-442144921
Looks like appimage-run degrades AppImages to self-extracting archives... what a crappy design!
In order to patch the linker paths, it needs to extract the files and modify them is my understanding.
Still, the least efficient option, and breaks lots of things like AppImageUpdate.
We used to do the same for type 1 support in AppImageLauncher, but now have plans to do the patching needed there in a FUSE filesystem. https://github.com/TheAssassin/AppImageLauncherFS
Ah, yeah, something like that would be awesome for AppImages on NixOS. Hopefully those who know more than I about NixOS internals are watching that approach!
We only need to patch the AppImage runtime there, though. But using a filesystem is an option for patching linker stuff, etc., too: just build a filesystem that shows the "contents" of the AppImage (i.e., mounts them in a hidden dir, and provides aliases for all files). Then, every binary could be patched on the fly during read()
operations.
@TheAssassin I wrote appimage-run as a quick hack to run a thing I needed, I don't claim it's The Proper Solution™ or anything like that. You're welcome to fix it.
IIRC I extracted them because the FHS wrapper breaks FUSE.
quick hack to run a thing I needed
No offense. I don't claim my old solution for AppImageLauncher is (and hopefully soon: was) a good design.
FHS wrapper
You mean the executable/ELF header (aka runtime)?
breaks FUSE
If you mean the ELF header, you just need to detect the size of it (which is possible using ELF libraries), and then can mount it using the offset
option. That's what the runtime internally does, too. If you just want to mount the data as-is, that's the easiest way.
By FHS wrapper, I mean this.
It is used for Steam support on NixOS, to provide a typical FHS environment to precompiled games. Here, I built a steam-run with the fuse package included, and ran an Inkscape AppImage I got from here:
~ > nix-build --no-out-link -E 'with import <nixpkgs> {}; (steamPackages.steam-chrootenv.override { extraPkgs = p: [ p.fuse ]; }).run'
/nix/store/h0q7pvg8xpiwf1p0icp69hfx7bsiy46p-steam-run
~ > /nix/store/h0q7pvg8xpiwf1p0icp69hfx7bsiy46p-steam-run/bin/steam-run bash
bash-4.4$ Downloads/Inkscape-0.92.3+68.glibc2.15-x86_64.AppImage
fusermount: /nix/store/v6l2sacryfr88yqq0pq7sia8wfgm9q31-wrapper.c:203: main: Assertion `!(st.st_mode & S_ISUID) || (st.st_uid == geteuid())' failed.
Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory
bash-4.4$
The wrapper.c mentioned in the error is the SUID wrapper NixOS uses because /nix/store can't have SUID executables.
There are other options, I tend to use bubblewrap instead of this wrapper (though I'm not sure it would help in this case), but that would have been more tedious to merge into nixpkgs.
In order to patch the linker paths
AppImages imho should be treated as monolithic objects, not to be patched. The proper solution is to install a linker in the "usual place" so that NixOS gains compatibility with "normal" binaries. Possibly this can be done in a private namespace so that it only affects those binaries that need it.
@probonopd It's not just the linker, it also needs a ton of libraries. And that's sort-of what appimage-run does, use namespaces to provide a filesystem that looks like what the AppImage expects, including linker and libraries at the usual places.
It seems more and more that NixOS never wanted to run arbitrary binaries and/or FUSE...
It seems more and more that NixOS never wanted to run arbitrary binaries
That is what I have my main "philosophical" issue with. If the NixOS developers think that every single application shall be specifically ported/modified to run on their particular OS distribution then, well, good luck with that. Then NixOS behaves like it is its own operating system with a tiny, tiny market share, rather than just another Linux distribution. How many application developers are going to care?
That (upstream maintaining a package in nixpkgs) is not an expectation I have observed in the community. FOSS applications are often easy to package, people just add things they want to use themselves, and there are a few (admittedly less pretty) solutions to get pre-compiled software to run.
That is what I have my main "philosophical" issue with. If the NixOS developers think that every single application shall be specifically ported/modified to run on their particular OS distribution then, well, good luck with that. Then NixOS behaves like it is its own operating system with a tiny, tiny market share, rather than just another Linux distribution. How many application developers are going to care?
There are standard patching techniques that can be applied to get any binary to run, and that's what appimage-run does. The real problem is that so many applications, including AppImage assume far too much about *nix systems just because most GNU/Linux distributions do things the same. The same types of problems often arise when porting to the BSDs.
@reardencode appimage-run doesn't really patch anything
We should really better get our act together to make all desktop Linux distributions to actually deliver on those assumptions (i.e., have less unnecessary differences), but that is just my 2 cents.
That (upstream maintaining a package in nixpkgs) is not an expectation I have observed in the community. FOSS applications are often easy to package, people just add things they want to use themselves
This approach works best for people who are
(Yes, I know that my statements are controversial but that's how one can look at things, too.)
@reardencode appimage-run doesn't really patch anything
Doesn't it apply the patchelf changes to get linkage to work?
(disclaimer: I don't use AppImages myself, but came upon here from the NixOS repo)
@TheAssassin FWIW, NixOS runs precompiled binaries and FUSE quite well. However, it sounds like (didn't test) it can't do both at the same time due to limitations of the Linux kernel (that from my reading are “no FUSE in a chroot in a mountns”, but again I didn't test). Which, I hope you'll agree with me, is a rather infrequent use case… maybe as infrequent as NixOS itself?
(also, actually there are usually ways to run proprietary applications without the chroot-in-a-mountns hack, using patchelf
, except for the worst ones like Steam -- it sounds like AppImages are currently in that last category)
Now, back to the actual topic: if AppImage can use environment variables to figure out where the linker is located for the in-image executables, then I think they will be possible to execute correctly on NixOS without the chroot-in-mountns hack. For the main executable that runs the whole image, we can just patchelf
on it and be good with that.
(Disclaimer bis: I am not familiar with the way AppImages work, so may be wrong with this. The idea is that we need a way to override all hardcoded paths to system utilities if we want to remove the chroot-in-mountns hack.)
I'm not an expert on Linux and most stuff you guys discussing here but I will be thankfull if you can help me with one basic use case: I want to run Beaker Browser AppImage on NixOS. I see 3 actors here:
The state is: error while loading shared libraries: libatk-bridge-2.0.so.0
I'm willing to make changes in places where I can do a PR but it's not clear to me if:
libatk-bridge
inside and so there's missing libatk-bridge
first in the excludelist and then in the appimage-run.libatk-bridge
so both exludelist
and appimage-run
are fine but there's a bug in the Beaker Browser packaging.This is my simple inexperienced user's view of my use case.
I'd say it's not a "bug" anywhere: Most mainstream desktop distributions apparently happen to ship libatk-bridge-2.0.so.0
as part of the default desktop installation whereas NixOS happens not to do that.
Since many AppImages are built against and tested with "most mainstream desktop distributions", it cannot be expected to work on NixOS unless NixOS, in its default installation, ships the same "least common denominator" set of libraries that "most mainstream desktop distributions" ship in theirs.
So, the "right thing to do" would be:
excludelist
. Note that the excludelist
lists libraries that we think must not be bundled with each application, as it is assumed that bundling those is considered harmful and the system-provided versions of those libraries should be used. This does not mean that if a system has all libraries on the excludelist
installed locally, then all AppImages will run. Since the application authors may have assumed other libraries (which are not on the excludelist
because they are not harmful to bundle) to also be "there" on each target system (most likely, based on evidence).Doesn't that contradict the idea that AppImages are “Linux apps that run anywhere” (wording from the front page)?
For AppImages to be Linux apps that run anywhere, the list would need to be a non-overridable excludelist
for which all other libraries would need to be bundled, so that every platform that wants to support AppImages know it only needs to provide the libraries listed in this excludelist
.
True.
So far we have been working from the assumption that we cannot influence what the "Leading Linux distributions" happen to install by default, and just take that set for granted.
Since this may slowly be changing (with some distributions specifically geared toward running AppImages) it might indeed be worthwhile to do what you are suggesting.
I have a probably dumb question: Why aren't AppImages statically linked binaries (that run on anything linux, even NixOS, without needing any shared object file on a specific place)?
The whole point about application portability in the linux world is about where do our applications expect which version of what shared object. So to me it seems to be a poor choice to use a dynamically linked binary to solve this problem about portability, as it again introduces assumptions about the target system.
I have a probably dumb question: Why aren't AppImages statically linked binaries (that run on anything linux, even NixOS, without needing any shared object file on a specific place)?
To make them really static, two things would need to be static:
This would increase the AppImage size and some people might think this would be "bloated".
Everything that goes into the AppImage.
That is not going to happen, unfortunately. Too many things cannot be built statically without a lot of effort (and almost no upstream project is willing to put that effort). Just shipping all the shared object files would be the saner variant here IMO.
people might think this would be "bloated".
Yes! That is the whole point of distro unspecific images of software. Shipping everything needed to run. If you want efficient unbloated packaging, go treat your distro's maintainers.
I was curious of whether appimages would run out-of-the box on NixOS since it is set up in a rather special way.
Downloaded the poster image from appimage.org:
Some info:
Weirdly(?)
ldd
says "not a dynamic executable"LD_LIBRARY_PATH
The weird "no such file ..." message is expected on nixos since
/lib64/ld-linux-x86-64.so.2
doesn't exist. We can get hold of the linker (and the few dependencies appimage seems to need) usingnix-shell
:No dice, but after a while I realized that the exported
LD_LIBRARY_PATH
might sneak into the appimage and cause trouble.So I tried an other approach frequently used to package binaries in nix: (first exit and re-enter nix-shell to make sure the environment is fresh)
patchelf
Some progress.. (note: my user can mount other fuse filesystems)
while true; do sleep 0.01; ls /tmp/.mount_*; done
'ing for fun I sometimes get something like:I can paste
LD_DEBUG=all
etc, if it might be helpful.Finally I also tried the Atom appimage with same results.
chroot
Having some OCD tendencies I tried a third approach setting up a chroot environment, but then fuse complained about SUID not being set (which doesn't happen outside the chroot)
Manual mount
Then I found https://github.com/AppImage/AppImageKit/wiki/FUSE and mounted the (unpatched) image manually and ran
AppRun
manually using the linker:Maybe something with
XDG_DATA_DIRS
? XDG_DATA_DIRS+=:$(realpath usr/share/) .. same errorstrace /nix/store/kj*ihqg-glibc-2.25/lib/ld-linux-x86-64.so.2 ./AppRun 2>&1 | wgetpaste
: https://paste.pound-python.org/show/rIzXiKZTGBnncIO6lAnR/And now I should really sleep :) (after trying to mount in /mnt/ just in case that was important)