## Major Problem when Upgrading a UserLAnd Linux Guest System via ‘apt-get’.

A fact which I had blogged about before was, that I had installed a Debian 10 Linux Guest System on the Android, Google Pixel C Tablet, using the Android app ‘UserLAnd’. This Debian 10 version was compiled by the package maintainers to run on an ARM-64 CPU.

Well, along with major updates to Debian 9 / Stretch, the Debian maintainers have just issued an update to Debian 10 / Buster, from version 10.0 to version 10.1 . The problem? When trying to perform the upgrade via ‘sudo apt-get’, the process hangs over the attempt to update or install ‘systemd’, and then configure it. Apparently, doing this requires full root privileges, because ‘systemd’ would normally control how services run in the background with ‘root’, but UserLAnd does not allow any part of its Guest System to run as ‘root’.

This could become a stumbling-block, in any future updates.

The ‘solution’ which I attempted to apply was, to remove everything that depends on ‘systemd’, and to re-apply the upgrade in total. But the net effect of that is, to remove many more packages than I intended to remove, including all things related to ‘Gtk 3′, ‘LXTerminal’, as well as key components that allow ‘LXDE’, the Lightweight Desktop Manager, to function at all.

Caution: This would have been a completely unsafe thing to do on a real computer, and was only plausible because the setup in question was virtual in some way, and also expendable. This would normally brick the computer…

When the makers of UserLAnd provided easy screen-shortcuts to install Debian and LXDE, they knew how to modify the installation script, to ignore whatever problems result from installing LXDE and its dependencies in a ‘proot’ed environment. But I don’t know those tricks. (:1) So at one point I had a partially gutted system, without LXDE really installed.

But the (Android) devs behind UserLAnd also provided a quick workaround for that problem. The next time I exited the corrupted session, and re-launched LXDE from the UserLAnd menu, this Android app recognized that LXDE was no longer installed, and simply reinstalled it for me, after which I could access it again.

Once I had done this, my wallpaper was a black background, and quite a few of the installed applications were no longer installed. And so what I needed to do next was, to run the equivalent of the following command:


\$ sudo apt-get install gnome-backgrounds clipit evince wxmaxima gcl firefox-esr libpam-cracklib



After having done this, I was able to select a wallpaper again, from the file chooser, and to regain most of the abilities I already had before.

I might still be missing some of the applications I once had.

But what all this suggests is, that the Linux Guest System should only consist of a vest-pocket system, with a small number of applications, because in reality any and all Linux applications may simply need to be reinstalled at some point in time. But, there is a way in which users are not ‘hosed’ if this happens:

Linux still segregates its data into a system directory, and a user home directory. Even though we have no form of access control within a ‘proot’ed system, even if certain applications are removed from the system directory, and then reinstalled there, our home directory will remember all our personal settings and data.

So the solution can be as quick as the initial disaster was.

My Linux Guest System is now down to taking up 4.86GB of Android application-data.

(Updated 9/09/2019, 16h15 … )

(As of 9/07/2019, 20h00 : )

I think I’ve gotten closer to finding out, what went wrong…

## Whether It Is Easy To Debian-ize A Kanotix Installation

One question which people often ask me, is “What is the advantage of Kanotix over Debian?” Kanotix is in fact a Debian-based distribution, but has been bundled to include advantages over straight Debian, including the ease with which certain features recognize our hardware and install.

The next question people typically ask me is, “Suppose I had installed Kanotix. What would I do if I no longer want it to be Kanotix, but rather want to revert it to a standard Debian installation?”

The answer to that question is twofold. Firstly, it is easy to remove the specific Kanotix repositories from our Debian Sources list, which ‘apt-get’ queries, to download packages. But there is a slightly more subtle side to this question, which is best answered with a concrete example.

As an example, Kanotix / Spitfire, which is based on Debian / Jessie, currently comes with LibreOffice 5.1.3.2-2. I just updated mine tonight. This differs from standard Debian / Jessie, which is only supposed to come with LibreOffice 4.4.4.3-3. The LibreOffice version that comes with Kanotix works 100%, even though it is a higher version number than what is standard.

But from time to time, both the Kanotix distribution and the Debian distribution will update the LibreOffice version we have installed, either way. This could be because certain security-related flaws have been discovered, as if we had not heard of enough zero-days yet. But if what we had was Kanotix, and if we had installed the version of LibreOffice that it offers as an advantage, then the version number would stay at 5.1.3.2-2 in my case. Any subsequent, incremental updates to LibreOffice, which standard Debian had to offer, would come as slight version increases over 4.4.3-3 – for example, standard Debian might come up with a LibreOffice 4.4.4.4 . In this case our problem would be, that our package manager would see that we have version 5.1.3.2-2 installed, and would not offer us the (slightly newer) version 4.4.4.4 , because that updated version would still be lower, than 5.1.3… So our version would stay frozen for some time, at least until the Debian team started to publish a version higher than 5.1.3.2-2 . Which would be, effectively never for Debian 8.

So in order really to get Kanotix off our system, we would next also have to uninstall LibreOffice 5.1.3.2-2 completely, which consists of numerous packages. And then we could reinstall OpenOffice 4.4.3-3 from the standard Debian repositories.

Doing so might also mean, that we had LibreOffice documents in our home partitions (user data), which happened to take advantage of LibreOffice 5.1.3 features, and which LibreOffice 4.4.3-3 does not know how to display correctly… And so what some of us might do, is just keep the LibreOffice version installed, that was once installed.

Something similar happens with VirtualBox, which is a GUI-oriented Virtual Machine, on which some of us will install Windows… Kanotix bundles a version of it, which combines all the features in one package, that package being of a higher version-number than standard Debian. Standard Debian will publish VirtualBox as a set of packages, but typically with a lower version number. In theory, the question could be more urgent here, of having to revert the version to the standard Debian version, before we install our virtual Windows, because major version mismatches here can stop our “Guest Machine” (that again being user data in its entirety) from running outright.

Dirk

One of the facts which I had observed about the Google Chrome browser version, which is meant for Linux, was that Google no longer provides a 32-bit version of its binaries. In keeping with this, Google has also removed the section in its code repository, which would make a 32-bit version available. Hence, I can only be subscribing to the 64-bit upgrades. Yet, my Linux computer ‘Phoenix’ has its package manager set up, to query a repository for both the 64-bit and the 32-bit versions of any package by default, and then to download and install the packages which are relevant.

In this earlier posting, I observed how this can lead to an error message when running ‘apt-get update‘. What I had done, was to make minor configuration changes like so, which I had needed to re-apply, after every upgrade to Chrome.

Well Google has caught up with the scenario which I was describing. As of their latest upgrade, their own ‘cron.daily‘ symlink will properly put the following source into ‘/etc/apt/sources.list.d/google-chrome.list‘ :





You may note, that the script from Google now includes the ‘[arch=amd64]‘ parameter, which means that I won’t have to make any manual adjustments to this configuration detail of my machine, every time the Chrome browser receives an upgrade.

Dirk

## Unattended Upgrades Did Not Run This Morning.

I previously wrote about the Debian package ‘unattended-upgrades’ Here. This morning however, this system did not install any upgrades, almost as if it had not run. Yet, I found no changes to any of the relevant configuration files. But I do have a tentative explanation as to why, maybe, this package did not run as usual.

When I prompted my KDE desktop tool to do the pending upgrades – that tool having been named “Tasker” in some versions of KDE, it showed that there was an upgrade pending for the package “Wireshark”. What I dimly seem to recall, is that the previous version of Wireshark had a severe bug. It is entirely possible that the unattended upgrades did not run this time, because I also have installed ‘apt-listbugs’.

If this supposition was true, then today would have been the first demonstration, of how this package will prevent an unattended upgrade from running. If true, this would come as a relief, because I previously had the fear that although this package would prevent a potentially damaging upgrade, it might also corrupt the state of ‘apt-get’. Apparently it will not. Let us keep our fingers crossed.

Dirk