It’s perfectly possible to run AppImages from within Crostini.

One of the assets which I have, is an Asus Chromebook, that has modest specifications (including mere 32GB of storage), but on which I did activate the Debian / Stretch flavour of Linux. I should also mention that this Chromebook has the Intel Celeron N3350 CPU, which runs the x86_64 instruction set. This latter detail is of some importance, as full compatibility with Linux will not be realized without it. Admittedly, the subset of Debian / Stretch packages that have been cross-compiled to ARM CPU binaries is limited, and what I’m about to describe in this posting will not work at all, on ARM CPUs (that were also the more-common CPUs for use with Android).

The virtual machine that runs Linux inside ChromeOS is also called “Crostini”.

One of the limitations which I’ve heard about Crostini is, that one cannot perform most loop-mounts in root mode. For that reason, there might be some misgivings about being able to run AppImage’s, because those require a user-space mount of a ‘SquashFS’ file system, and also require the existence of a kernel module to do so.

Therefore, I am most happy to report, that on my Linux setup, and with up-to-date Chrome 85…, I am able to run AppImage’s after all, that were meant for Linux, and for the 64-bit, Intel / AMD CPU family.

As an example, I was well-able to download the Kdenlive video editor, in the form of the Linux AppImage, and to get it to run under ChromeOS. I find that often, the video editing features available from Google Play / Android apps are way too limiting.

Thus, I am finding new ways to enjoy my Chromebook and its Linux subsystem. I would warn people though, that, before running AppImage’s, they install a somewhat complete set of Linux applications and libraries.


 

(Update 9/10/2020, 20h55: )

Continue reading It’s perfectly possible to run AppImages from within Crostini.

How to run my AppImages using FireJail.

First of all, I’d like to do some basic defining:

What is FireJail? It’s a type of sandboxing program, which can be run from the command-line, and which allows users to run certain programs which they do not trust, even with user-level access to their Linux computers.

What is an AppImage? It’s a special kind of file, that has execute permissions set, but that is also linked to its own, local version of many libraries, thereby circumventing compatibility issues. But, the way an AppImage is made, consists of a file-system image, that the kernel actually needs to mount, within which these libraries and executables exist, and that gets mounted read-only by default. The security of the computer really depends, on the kernel making sure, that none of the files in this virtual FS can be mounted, with their SETUID bits taking effect. (:1) (:2)

However, even under Linux, there is some risk in ‘arbitrary code’ running with the username of the person who caused this, since most of that user’s personal data is also stored under his or her username. Further, modern Linux computers sometimes ask for requests coming from user-space, resulting in actions by the O/S, and with elevated privileges.

The problem in running certain AppImage’s using FireJail is the fact that the most recent AppImage’s use ‘SquashFS’ as their (compressed) image, while older AppImage’s used an ISO container, which did not offer (much) compression. The version of FireJail that I can install under Debian 9 / Stretch is still of a variety, that can only run AppImage’s built with ISO Images, not with SquashFS. The following bulletin-board posting correctly identified the problem, at least for me:

https://github.com/netblue30/firejail/issues/1143

Following what was suggested there, and wanting this to work, I next uninstalled the version of FireJail that ships with my distro, and cloned the following repository, after which I custom-compiled FireJail from there:

https://github.com/netblue30/firejail

I got version 0.9.63 to work, apparently fully.

This latest version of FireJail does in fact run my AppImage’s just fine. Not only that, but now I can know that other, more recent AppImage’s can also be run with FireJail (on my main computer).

If people want to obtain the accompanying GUI, then the way to do that is, to custom-compile the accompanying ‘firetools’ project:

https://github.com/netblue30/firetools

This parallels how the Debian ‘firetools’ package enhances the Debian ‘firejail’ package…

Screenshot_20200828_140220

 


 

 

But, if people are only willing to use the version of FJ that comes with their package manager, then my AppImage’s will never run, for the reason I just explained.

N.B.:

When running AppImage’s using FireJail, one precedes the name of the AppImage with the ‘--appimage‘ command-line option, because they are a special case.

(Updated 8/29/2020, 13h05: )

Continue reading How to run my AppImages using FireJail.

Disabling upowerd on a Desktop Linux computer that never actually had a battery.

One of the facts which I’d like to make sure the reader knows, is what, exactly, the process ‘upowerd’ is responsible for on any Linux computer, lest the reader disable something that he or she may really need.

Many computers, including laptops, have batteries. ‘upowerd’ is the Linux process that monitors the battery, or the batteries, in case there is more than one to monitor. If the computer has batteries to monitor, then this process is essential and should not be disabled. But, in certain specific other cases, this process can become a problem, as it recently was on my desktop computer named ‘Phosphene’, which is running Debian 9 / Stretch, which has Plasma 5.8 as its desktop manager, and which will only ever run on A/C power, due to the very way in which its hardware is designed.

Several months ago, I noticed that the ‘North Bridge’ of this computer – an essential chip on its motherboard – was becoming rather hot. And the motherboard in question, the ‘Sabertooth X58′, manufactured in the year 2011, was already famous for the design flaw that causes its North Bridge to become 76.5⁰C hot when idle, which is actually hotter than the GPU on that computer will normally become, when pressed to work hard. Several Months ago, the North Bridge temperature when idle was 80⁰C or even 81⁰C! Whether it’s actually safe for a chip to be that hot is a subject open to opinion. This temperature will not cause an immediate failure, but if the chip is so hot continuously, then its lifespan will become shorter, than what the lifespan of chips is supposed to be, in general.

Therefore, months ago, when I first noticed this, I opened up the tower / desktop computer and examined it, to look for failed cooling fans, etc. There was no such cause for the elevated NB temperature. Not being able to remedy the problem, I just left it that way.

But only yesterday, I noticed that the process ‘upowerd’ was consuming an inordinate amount of CPU time. On the octa-core machine, that process was consuming maybe 1% of available CPU time, which was quite a lot, considering that there should have been nothing for it to do. And, never having noticed this before, it seemed possible to me that ‘upowerd’ may have been consuming 1% of available CPU time (unnoticed), since months ago.

When ‘upowerd’ misbehaves in this way, sometimes this happens, because of hardware signals, such as perhaps, a battery which continuously disconnects and reconnects, etc… Therefore, before a software kludge is attempted, all possibilities need to be followed, to find hardware causes for this behaviour, to which ‘upowerd’ would simply be responding in a normal fashion. Yet, even given hardware reasons to be active, ‘upowerd’ should not be consuming much more than 1% of available CPU time, in case the reader has some situation where this process is consuming, say, 10% of the CPU.

Continue reading Disabling upowerd on a Desktop Linux computer that never actually had a battery.