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

Under Linux, the command

apt-get update

Is safe, and only refreshes the packages list stored on the client, to reflect changes that have been made in the repository. OTOH,

apt-get upgrade

Tells the package manager, simply to upgrade all packages, which have newer versions in the lists, from the versions currently installed. In principle, this sounds logically correct. But there is an alternative to this, which is called

apt-get dist-upgrade

The difference is, that ‘dist-upgrade’ is smarter than ‘upgrade‘ about global changes that might take place, due to changes in the overall Debian Distribution – hence the ‘dist’ – which can affect which directories files and configuration changes need to be stored to.

In practice, ‘d-u’ is always safer than just ‘upgrade‘, and does everything ‘upgrade’ is supposed to do. Therefore, we generally give the command

apt-get dist-upgrade

Dirk

## One Reason I now Feel that the Linux Update Process is Stable

Back in past years, the habit I had had with my Linux computers was such, that I would not do a complete upgrade of all installed packages. Instead, I would often tell my package manager to install some new packages, and view the message it generated, according to which many packages were to be held back and not updated, as part of the new installation. I used to acknowledge this in general, and allow it to happen.

By contrast, I did notice how often Windows Update does its job, and how my Windows computers were never or seldom broken by a Windows Update. However, it had happened to me on occasion, that the Linux computers could get into some sort of stability issue, over upgrades I had done. And so I had reached the vague conclusion, that Windows Update was somehow better, than the habit of doing complete upgrades under Linux.

What I now have is two computers, on which all the packages I have installed are at their most recent version, due to the ‘unattended-upgrades‘ package which I have installed, and which I wrote before in This Earlier Posting.

What I now find, is that my Linux computers that are up-to-date, are at least as stable as my Windows 7 and Windows 8.1 machines, if not more stable. And so advice which I was once given but had ignored, seems to have been accurate, according to which my earlier practice of only upgrading a minimum of libraries, was a bad practice, and according to which doing so, introduced stability problems of its own.

Having said that, If we are given a Debian / Linux machine which requires upgrades to a large number of packages, let us say to more than 20 packages, then we effectively need to do a ‘dist-upgrade‘ to achieve that most reliably, and even then, this one-time action can fail, and can leave us with an unstable or broken system.

Dirk

## There has been a Dist-Upgrade on my Server.

This server is hosted on a Debian / Jessie (Linux) computer which I own and run myself. Under Debian – Linux systems, the most thorough kind of update which can be carried out is called a ‘dist-upgrade’ or a ‘d-u’ for short. Just this evening, I saw that suddenly there were 93 software packages, which all did need an upgrade, and saw, that I could not just leave this type of upgrade to the usual, automated services. Therefore, I decided to administer the 93 package-upgrades given, via a dist-upgrade command. This can be stressful, or exciting, or both, because it can give a Linux user an improvement, or it can in some cases actually cripple our systems. I’m glad to say that this Linux box I name ‘Phoenix’ did not get crippled. It’s still fully bootable.

But due to this procedure, the Web-server was also down, from 20h15 through until 20h40 or so. I see that my blog is still here though, after the d-u .

I think that most software updates can be fun and games. But this particular upgrade also chose to include my graphics driver, which I was particularly fussy about. The past version of the graphics driver on this box was extremely stable, and I was trying to avoid doing any sort of upgrade to it, but now doing so was the only way to keep my box compatible with future upgrades.

It has sometimes happened to me, that the screen might just freeze – even though it’s a Linux computer – due to stability problems with other graphics drivers – especially with the ‘mesa’ driver, which tries to software-render an OpenGL equivalent. But what has been most stable for me in recent months, was the ‘GLX’ driver, which does full hardware, OpenGL rendering as it’s supposed to, and which under modern Linux systems is even capable of a ‘TDR’ equivalent, a Timeout Detection and Recovery, which will restart a crashed GPU without harming the active session.

If in the near future I find that my screen does freeze, or that there are TDR issues, a sinking feeling will go through my heart, because that would signal that a completely stable graphics driver has been replaced unnecessarily, with an unstable one. And in the act of doing so, all my package-management scripts even recompiled the DKMS kernel module for the graphics driver in question, because that is the correct way to install it.

Oh Yes, I see that the Apache Web-server software, which my machine hosts, has been given an upgrade as well. But as I see it, this was the least likely set of packages, for the maintainers to have botched. So it’s my full assumption that Web-server activity will continue without error.

Dirk