How to run a Appimage in Puppy Linux

[bigpup]

Running software as a Appimage package file in Puppy Linux, is easy, if you know what you may need to do, to get it to run.
Not all Appimages are created the same.
So the dream, is not totally simple, to have a program package file, that just works, in any Linux OS.

As you can see by reading some of the following posts, about issues.
Depends a lot on the appimage, how easy it will be, to get it to run.
.
.
Note:
Appimages are downloaded not having exec permissions.
This is a security feature, so the file cannot run on it's own, after it is downloaded..
.
.
The following are ways, that will usually work, to get an Appimage software package file to run..

Simple method:
Download the appimage software package file to a location you can find it.
Navigate to that location in Rox file manager.
Right click on the Appimage file.
Select properties.
Give the AppImage exec permissions, for all exec options.
Left click on the appimage file and it runs.

A little harder simple method:
Go to the directory where your AppImage is.
Make sure you've given it Exec permissions.
In open area of the Rox window, right click.
Right-click menu->Window->Terminal here.
A terminal window should open.
Enter the following:-

Code: Select all

./xxxxxxxxx.Appimage

.....where "xxxxxxx" is the exact name of your AppImage.
Type the name EXACTLY as it appears. (Font is case sensitive)
Now hit Enter.

Harder method that may be required:
Many AppImages won't always fire-up straight-away.
Often, these are Electron-based.
Since the Electron 'framework' is built around a stripped-back Chromium browser.
Where this is the case, you usually have to add a switch command to run it.

Code: Select all

--no-sandbox

to get them to work.

Go to the directory where your AppImage is.
Make sure you've given it Exec permissions.
In open area of the Rox window, right click.
Right-click menu->Window->Terminal here.
A terminal window should open.
Enter the following:-

Code: Select all

./xxxxxxxxx.AppImage --no-sandbox

.....where "xxxxxxx" is the exact name of your AppImage.
Type the name EXACTLY as it appears.
Now hit Enter.

A way to get around will not run as root:.
To run a program as spot.
Making program think it is not running as root.

Code: Select all

run-as-spot

goes in front of the terminal input.
Example:

Code: Select all

run-as-spot ./xxxxxxxxxxx.appimage

xxxxxxxxxx is the specific name of the appimage file.

These posts may apply to trying to run as spot:
viewtopic.php?p=34550#p34550

If Appimage still will not run.
Some Appimages may not have everything in them, needed to run.
There are some common files and programs, that all Linux OS's should have.
It may need some of these, and Puppy may not have, whatever it is.
Running the Appimage from the terminal, will usually tell you what is wrong, if it does not run.
Usually that missing stuff can be added to Puppy as needed.
The Puppy Package Manager(PPM) is a good place to find what is needed, download, and install, whatever it is.

NOTE:
If still having issues.
Read some of the suggestions in other posts of this topic.

[bigpup]

Any information you can add to this, please post, and I will update the first post.

If I got anything wrong, Please correct me!!

[dancytron]

For Elements applications, Instead of using --no-sandbox, you can have it run as a different user. I'm assuming the normal way to run browsers as "spot" in Puppy would work.

[peppyy]

I have had a couple like https://appimage.github.io/VLC/ that even with --no-sandbox or --run-as-spot I still get this message.
VLC is not supposed to be run as root. Sorry.
If you need to use real-time priorities and/or privileged TCP ports
you can use ./VLC_media_player-3.0.11.1-x86_64.AppImage-wrapper (make sure it is Set-UID root and
cannot be run by non-trusted users first).

Don't know if this helps with figuring out what is happening or not.

[bigpup]

To run a program as spot.
Making program think it is not running as root.

Code: Select all

run-as-spot

goes in front of the terminal input.
Example:

Code: Select all

run-as-spot ./xxxxxxxxxxx.appimage

xxxxxxxxxx is the specific name of the appimage file.

[peppyy]

Now I get.

run-as-spot ./VLC_media_player-3.0.11.1-x86_64.AppImage

fusermount: mount failed: Operation not permitted

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

I see there is a workaround used by mounting the appimage or installing fuse at the link mentioned above. It also states that a type-1 AppImage is an ISO. Not sure if I want to try that on this machine, Might try it live if I get a chance. Funny it won't run as root and won't run as spot.

[mikeslr]

The publisher of VLC --maybe other 'finicky' applications-- structures them to run under 'major distros' where the User, by default, lacks root privileges and is confined within his/her Home Folder with respect to installing applications [unless by first giving the magic password he/she elevates him/herself to 'Administrator' [Talk about dumb and inefficient But like the qwery-keyboard, once something becomes part of 'The Culture' it's hard to weak people off of it].

For the last couple of years Mike Walsh has been adapting web-browsers published with those limitations to run under Puppys. While now his publications are portables, before the portables he published SFSes. The primary structural difference of those SFSes is that they located almost the entire application within the spot folder: initially in /root/spot, later --taking a page from FatDog-- in /home/spot, with /home being a top-level folder. The only files relating to these SFSes not in 'spot' were those necessary to create menu entries and move files into/out-of Spot and, of course, start the application in /spot from Puppy running as Root. And, IIRC, scripts with arguments changing permissions to 'spot' were located in both the /usr and the Spot folder.

You might try to locate one of Mikes old google-chrome.sfs and examine it. Or perhaps one from FatDog which IIRC still employs that technique. At any rate, the idea would be to locate the AppImage within /spot.

[peppyy]

@mikeslr You gave me an idea so I moved the appimage to spot then logged into spot with.
root# su spot
root$ cd ~
root$ whoami
spot

Then I used sudo

root$ sudo ./VLC_media_player-3.0.11.1-x86_64.AppImage

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:

I am not sure which password to try other than woof
I remember years ago the default on a lot of distros was toor.

[williams2]

sudoo never asks for the administrator's (root's) password.
sudo wants the user's password, in this case, spot's password.

The default password for root is woofwoof.
But sudo is not asking for root's password.
Root's password won't work.
Sudo wants spot's password.

There is no password set for spot.
To use spot's password, you must set a password first.
You can set spot's password by typing passwd spot

But spot is a much more limited user than the unprivileged user that most other distros use.
They can use sudo to do anything that root can do.
Puppy's spot is much more limited.
Puppy's spot can not use su or sudo.

# su spot
$ su
su: must be suid to work properly

[fredx181]

Following the instructions from here https://github.com/AppImage/AppImageKit/wiki/FUSE for Arch Linux made it work for me:

For example, on Arch Linux:

If you are seeing "fusermount: mount failed: Operation not permitted"

sudo chmod u+s `which fusermount` (it adds the "sticky bit" AFAIK, btw, no "sudo" needed when running this command as root).

Then on FossaPup it works fine for me: run-as-spot ./VLC_media_player-3.0.11.1-x86_64.AppImage

Fred

[fredx181]

I think it's a bug in FossaPup, other systems I use have the "sticky bit" (the "s" in -rwsr-xr-x) in /bin/fusermount as it should be IMO:

Code: Select all

ls -l /bin/fusermount
-rwsr-xr-x 1 root root 34896 apr 22  2020 /bin/fusermount

EDIT: Hmm.. checked other puppies and they don't have the sticky bit either on fusermount

[peppyy]

@fredx181
That got it to fire although it appears the appimage has errors in fossa64.

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

Aborted
My main reason for wanting to try it is because the one I have in fossa64 has issues. I thought perhaps the appimage would run better.

[fredx181]

@fredx181
That got it to fire although it appears the appimage has errors in fossa64.

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

Aborted
My main reason for wanting to try it is because the one I have in fossa64 has issues. I thought perhaps the appimage would run better.

Strange... the appimage works OK for me (using FossaPup64 version 9.0.3).
Can't understand btw that it says "even though it was found" about plugin "xcb".
EDIT: Maybe a google search on the error could shine a light: https://www.google.com/search?q=qt.qpa. ... e&ie=UTF-8

@bigpup perhaps a thing to mention in first post about that some types of appimages run only when the sticky bit is set on /bin/fusermount.
viewtopic.php?p=34551#p34551
edit: I think specially when running as spot

[peppyy]

Hmm, I wonder if I had an upgrade issue somewhere since install. I have been having problems with certain graphics for about 4 to 5 months. mine says,
fossapup64 9.5 Build GCC: 9.3.0 (which is different from your 9.0.3). Have you updated your kernel? Mine reports 5.4.53.

I was working to get Zone Minder installed a couple months ago and got everything installed and working until I got to Mysql so I have been adding and removing things with PPM.

I am starting to think I may have to revert to some of the original files to get things back in order? I do have a backup from a week or so ago of my pupsave file, but I am thinking I might have to get some of the original boot files from the cd?

Another thought is, I have had an issue with power outages, I am on an ext4 partition though so it should be fine.

I also installed the same thing on my wife's machine last year, (an all in one with touchscreen) and hers is rock solid.

[fredx181]

Hmm, I wonder if I had an upgrade issue somewhere since install. I have been having problems with certain graphics for about 4 to 5 months. mine says,
fossapup64 9.5 Build GCC: 9.3.0 (which is different from your 9.0.3). Have you updated your kernel? Mine reports 5.4.53.

Yes, I'm using older FossaPup, kernel not updated, version is 5.4.47, no idea if that makes the difference.

I am starting to think I may have to revert to some of the original files to get things back in order? I do have a backup from a week or so ago of my pupsave file, but I am thinking I might have to get some of the original boot files from the cd?

Could be that re-installing some packages will help, or other solution provided here:
https://forum.qt.io/topic/93247/qt-qpa- ... -was-found. (e.g. reinstall libxcb-xinerama0)

Re: Set sticky bit on /bin/fusermount: viewtopic.php?p=34551#p34551
From some further investigating I've learned that it's only needed to have set the sticky bit when running an appimage with "run-as-spot".
(nothing to do with some special 'type' of appimage, as I first thought)

[geo_c]

I have a mixed bag of portables and Appimages. Some with @mikewalsh launch scripts, others just straight appimage files, and some with an AppRun script. I was launching most of them from the desktop by dragging the launchers from Rox to the desktop, and assigning the icon. The desktop got cluttered. So I moved them all to Cairo dock. At first I couldn't easily make them launch, until I found a system:

• Open a Rox window and find the final target, (either a launch script, appimage, or AppRun as has been the case for me so far.)

• Right click on the Cairo Dock, choose 'Cairo-Dock+Add+Add+Custom launcher' (an edit menu will open)

• Right click the target file in Rox and choose Rename. ctrl-A to select the entire path of the filename, then ctrl-C to copy the full path and target name, then carefully cancel the Rename.

• In Cairo-Dock's menu, paste the launcher's path/filename in the field that says Enter a command.

• Use the other fields to name and assign an icon, position in dock, etc.

• click Apply then Close

You should now have a launcher in the Cairo Dock that will run the portable/appimage. If you point to the launcher script, then any config placements and such that are included in the script will also be applied. I have downloaded some appimages straight from the developer without any special settings, so my guess is that these create overhead in root. But that is another subject.

~geo

[mistfire]

QuickPup64 support Applmage apps with ease by just double clicking it.

[UNLSHD]

I am not sure which password to try other than woof
I remember years ago the default on a lot of distros was toor.

Not sure either !

[williams2]

I am not sure which password to try other than woof

The default password for root, for most Pups, is woofwoof

sudo does not ask for root's password.
When sudo asks for the password, sudo wants the password of the unprivileged user.

If you are running as spot and sudo asks for a password.
then sudo is asking for spot's password.
Sudo is not asking for root's password.
root's password won't work.

In most Pups, spot's password is not set, by default.
You need to set a password for spot before you can use it.
Like this: passwd spot

I don't think spot can use sudo unless it is configured to work with sudo.
At least, I think the suid bit of su needs to be set.
But that sets the suid bit of busybox and all the executables that are symlinked to busybox.
Which is probably not a good idea.

[dellus]

LibreCAD now provides an Appimage: https://github.com/LibreCAD/LibreCAD/re ... 4.AppImage.
It doesn't run in Fossapup 64. When I tried it from console it said: libdl.so.2: cannot open shared object file: no such file or directory.
I then tried Busterdog 64 and Fossadog 64, it worked in both.
libdl.so.2 and the target file libdl-2.28.so respectively libdl-2.31.so do exist in /lib/x86_64-linux-gnu in all three cases.
So why does it not run in Fossapup 64? What can be done?

[mikewalsh]

@peppyy :-

I know this thread is months old now, but I'll just add my two-penn'orth, FWIW.

With regard to the "xcb" plugin thing, it's worth remembering that Qt, just as with Python, needs a matching, correct version of the relevant lib for plugins to work; Python is just the same.

Sometimes, it's possible to get round this by unpacking the AppImage with the

Code: Select all

--appimage-extract

....'switch', then assembling the thing in a self-contained directory, and using a 'launch' script that points the app at its own Qt5 libs via an LD_LIBRARY_PATH clause (many have everything they need to run, since this is one of the hallmarks of a properly-built AppImage.....it doesn't NEED anything from the host system it's running in.)

Doesn't always work, mind you, but it's worked for me on several occasions over the past 2 or 3 years when building some of the many portables I've put together... It's extra work, of course, but then this has always been the way of things with Puppy. You get used to it..!

Mike.

[mikeslr]

In theory, AppImages are 'self-contained': that is included within are all dependencies. In theory, an AppImage mounts @ /temp and doesn't 'mix' with or look to your system files: e.g., try to make use of them. Maybe it's just Puppys; After all, AppImages are constructed to run under only a couple of 'major distros'; Puppy isn't one of them and Puppys do some things differently. At any rate, sometimes Images don't work OOTB under Puppys.
The first thing to do is try to find out why. Try running it via a terminal:
Copy it to a /temp folder; rename it to something short (it doesn't care what's name is; the name is for your benefit). Open a terminal in that folder and type, code "./ NAME.AppImage" --without the quotes. The terminal output may provide a clue.
Unpack it. There are other ways, but I find this easiest to rememeber: Right-Click NAME.AppImage and select UExtract from the popup menu. Within the folder created with the ending 'extracted' you'll find what is essentially a portable or rox-app. You can file-browse within it to its binaries, right-click them and from the popup menu select ListDD =ListDynamicDependencies. The missing tab at the bottom will generate a report of what's missing.
Dont take it literally. ListDD has examined your operating system, not the contents of the folder you're examining. Leave the report open. File browse to the TOP your suspect folder, Right-Click an empty space and from the pop-up menu select "Window>Shell Command". A panel will open at the bottom. Type 'pfind' without the quotes. pfind will open, click the "Current Directory" button in the Right-most Panel. Then copy & paste the files ListDD reported missing. Don't copy the entire name: leave off the version number. If you have the 'wrong' version you might only need to create a symbolic link to it.
If the problem is missing libs, after finding them you may be able install them into your operating system and run the AppImage as an AppImage. But you can also include them in your AppImages Folder and run the AppImage as a portable. This suggestion is a variation of how I got krita-5.0.6-x86_64.AppImage to run under Fossapup64. See this post for details viewtopic.php?p=57779#p57779 and the link to the AppImage.
p.s. Thanks, bigpup, for reminding me I hadn't provided that link.

[soniabu]

good, thx bigpup
sonia

[Phil_54]

I have downloaded and am using librewolf AppImage. I have this saved outside the frugal install so available to other puppies.
In Fossapup64 CE I opened it up run-as-spot. When downloading anything, it prompts by default the spot/Downloads folder.
In Fatdog64 by same method it prompts download as /root/Downloads, not spot. (I maybe will ask this in Fatdog forum, but this is an appimage question first.)
In both cases if I print a screen to save as pdf, the location is defaulted to root, not spot.
Therefore is run-as-spot for appimage browser limited in its security to save only downloads to spot (apart from Fatdog64 which doesn't do that apparently)?

[mikewalsh]

I have downloaded and am using librewolf AppImage. I have this saved outside the frugal install so available to other puppies.
In Fossapup64 CE I opened it up run-as-spot. When downloading anything, it prompts by default the spot/Downloads folder.
In Fatdog64 by same method it prompts download as /root/Downloads, not spot. (I maybe will ask this in Fatdog forum, but this is an appimage question first.)
In both cases if I print a screen to save as pdf, the location is defaulted to root, not spot.
Therefore is run-as-spot for appimage browser limited in its security to save only downloads to spot (apart from Fatdog64 which doesn't do that apparently)?

@Phil_54 :-

As I understand it, FatDog doesn't save to /spot/Downloads because it already runs a multi-user environment with restricted permissions for anything internet-facing. As for Librewolf specifically, I honestly couldn't say. I only banged together a couple of 'portable' builds using it 'cos others seemed to want one; I never really investigated it further, 'cos I'm not a fan of 'zilla-based browsers.

Sorry I can't answer you any better than that, 'cos I just don't KNOW. Mikeslr might be able to respond to your queries better, because he's investigated this business of 'run-as-spot' browser behaviour under Puppy in quite some detail. He may well 'chime-in' later on.

The only downside to using browser AppImages is the inability for them to run updates, due to the 'unpacked' AppImage running in /tmp for the duration doing so with "read-only" permissions. That 'read-only' stuff also seems to prevent certain other browser functions from operating as you might expect; this is why I gave up on a brief flirtation with "Marmaduke's" AppImage builds of Ungoogled Chromium, and now use the tarball instead (which is smaller, too!) Unfortunately, you have no options with Librewolf, since it only comes AS an AppImage.

(I'm getting to be something of an anachronism round here, 'cos I appear to be one of only a handful of current Puppy users that don't care about running a browser as root. Most of the current membership now seem to be far more security-conscious than they ever used to be in the past. Or maybe that's a direct result of the way the internet - and malware exploits specifically - are developing these days...)

(*sigh*)

Mike.

[CatPup]

I'd like to point out that on FossaPup 95 and 96 I've been running LibreWolf AppImage flawlessly. No need to do any tampering or installing. Just make it executable and it'll just work!

Also I don't get why OP is suggesting to use the "--no-sandbox" option.

[geo_c]

I'd like to point out that on FossaPup 95 and 96 I've been running LibreWolf AppImage flawlessly. No need to do any tampering or installing. Just make it executable and it'll just work!

Also I don't get why OP is suggesting to use the "--no-sandbox" option.

Big advocate of LibreWof appimage here. It runs ootb on all OS's I use. I also move the profile folder /root/.librewolf into the directory where the appimage resides and symlink it back to /root so it functions like a portable, being synced across all OS's.

Hasn't ever failed to work flawlessly in Fatdog, vanilladpup, fossapup95 and 96, s15pup, KLV-airedale, KLA-xfce, and KLV-OT2. Easy to update also.

[fredx181]

Also I don't get why OP is suggesting to use the "--no-sandbox" option.

That suggestion is only for in case an appimage won't run as 'root' (as goes for many 'Electron-based' programs).

[BarryK]

Hi guys,
I have started planning an appimage installer, and I need a type-1 appimage to play with, but can't find one.

Does anyone know where one is located?

[fredx181]

Hi guys,
I have started planning an appimage installer, and I need a type-1 appimage to play with, but can't find one.

Does anyone know where one is located?

If you are looking for the older appimages (what you call type-1 perhaps ), see here: https://sourceforge.net/projects/portable/files/
The newer "type' is different, 64-bit mostly, made (in a way) by using mksquashfs (extract by e.g. ./my-appimage --appimage-extract, and you get "squashfs-root" directory)