## How an old problem with multiple (Debian / Linux) sessions seems to require an old fix.

One of the facts which I recently updated my postings with is, that I have the ability to run multiple sessions on one PC, and to switch back and forth between them, by using the key-combinations <Ctrl>+<Alt>+F7, <Ctrl>+<Alt>+F8, etc. According to that update, each session could theoretically use either ‘Plasma 5′, or ‘LXDE’ as its desktop manager, even though I’d choose an actual LXDE session for only one of my defined usernames.

When I was recently testing this ability, I found that a Plasma 5 session which had locked its screen (which I had switched away from), using the built-in Plasma 5 locker, would start to consume 1 CPU core at 100%, as was visible from within the other session. And, it appears that This is a bug which has been known for a long time, on computers that have the proprietary NVIDIA graphics drivers, as my computer named ‘Phosphene’ does. This computer is still based on Debian 9 / Stretch. Apparently, according to common lore, what one is supposed to do about this is, to create a file named such as ‘dirk.sh’ (in my case), in the directory ‘/etc/profile.d’, which is supposed to set two environment variables globally like so:

# An attempt to prevent klocker from consuming 1 CPU core 100%
# when multiple desktop sessions are active...

export KWIN_TRIPLE_BUFFER=1
export __GL_YIELD="USLEEP"



Unfortunately, this backfired on me when I tried to implement it, in that regardless of which way I tried to do so, ‘kwin’ would just crash in the session that’s supposed to be using ‘Plasma 5′. An additional mystery I ran in to was, that my attempts to set ‘__GL_YIELD’ would simply get reset somewhere, unless I had also set ‘KWIN_TRIPLE_BUFFER’. Only if I set both, would setting either reveal as successful, using an ‘echo \$…’ command. (:1)  Therefore, what I really needed to do was, to turn off the Screen-Locking which is provided by Plasma 5 itself (for both my usernames), and to install and use ‘xscreensaver’ instead. However, doing that has two obvious caveats:

• Under Debian 10 / Buster and later, ‘xscreensaver’ is no longer fully supported, unless one also reconfigured the new, Wayland display manager to act as an X-server proxy, And
• Even when I apply this fix, which means that I’ve completely disabled ‘klocker’ in my settings, at the moment I tell Plasma 5 to launch a new, parallel session, foregoing-which causes <Ctrl>+<Alt>+F8 just to lead to a blank screen, Plasma 5 will lock the current session – Using ‘klocker’ again, and causing 100% CPU usage to become visible, again, from the second session.

What I find is that, once I’ve used my Plasma 5 session to create a parallel session, I need to switch to the first session once, using <Ctrl>+<Alt>+F7, and unlock that one. After that, both my Plasma 5 sessions will only lock themselves, using ‘xscreensaver’. And aside from that short, crucial interval, I haven’t seen 100% CPU-core usage again.

I should add that, for certain purposes, I sometimes choose only to install the CPU-rendered ‘xscreensaver’ packages, and deliberately do not install the hardware-accelerated ones. And in this case, the hardware-accelerated screensavers were omitted, simply because they could start running the busy-wait loop again, only this time, when invoked by ‘xscreensaver’.

(Update 3/24/2021, 13h55… )

## Installing Chrome on Old Debian Versions (Redirect from Installing Old Chrome Version on Debian).

In recent weeks I’ve been noticing some rather odd behaviour, of the Linux version, of the most up-to-date Chrome browser. In short, every time I launched the browser on my Debian 9 / Stretch computer, that has the Plasma 5.8 Desktop Manager, certain malfunctions would set in, specific to the desktop manager. I waited for several Chrome version upgrades, but the malfunctions persisted. And, as far as I can tell, the problem boils down to the following:

Google will only distribute the latest Chrome version, and when they tag the line which one is supposed to have in one’s Sources.list with ‘stable’, apparently, they mean both the Stable version of Chrome, And, for the Stable version of Debian. According to Google, Debian 10 happens to exist right now, because that is the “stable” version (of Debian), but, Debian 9 and Debian 8 don’t exist anymore. Except for the fact that many people could still have either installed.

## 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. (:1)  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.

(Updated 4/04/2021, 20h10… )

## 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…

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: )