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…

There exists a utility-program named:

 


/bin/systemd-machine-id-setup

 

This is a program which will get called, every time an attempt is made to reconfigure the ‘systemd’ (Linux) package. The problem is the fact that within this Guest-System, any attempt to run this program results in a generic message, stating that it cannot link to a shared object – as in, from a shared library.

What may be happening here is that this utility was used by UserLAnd, when the ‘proot’ed environment was set up, thereby leaving a valid UUID in the file:

 


/etc/machine-id

 

Furthermore, these files can exist on systems which do not have ‘systemd’ installed. Therefore, they do not belong to the actual package by name. And, my sessions do not have a valid ‘dbus’ running.

Yet, this executable may be linked to a library that’s outside the ‘proot’. The library in question may disappear from view, as soon as the main process enters the ‘proot’. Running ‘sudo ldconfig’ doesn’t fix the problem. This would explain why the Android app can install the package, but why attempts to reconfigure it from within the ‘proot’ fail. And why any upgrades attempted from within, that attempt to reconfigure this package, also fail.


 

Many of the packages that remain ripped out, would have been essential for proper session-management, or user-management, or the GUI-based configuration of the device’s settings, which I don’t expect to gain access to, or were audiovisual in nature, even though my VNC-Sessions are without sound. So I should be okay for the moment. I believe I may also be missing PAM.


 

(Update 9/07/2019, 20h40 : )

Actually, ‘libpam-modules’ was still intact. Only ‘libpam-cracklib’ was thrown out.

These modules would be important if, for some reason, I wanted to allow other computers to access sessions that exist on this little tablet, which is unlikely. But they might also be important if, for some unknown reason, I wanted to set or change passwords within my already-authenticated VNC Session. Or, if some compatible application simply wanted to use my established passwords to authenticate something.


 

(Update 9/08/2019, 10h35 : )

From what I’ve read, the utility program I mentioned above was linked to the library from the package ‘libc6-udeb‘. Its only purpose is to install a Debian System, not to be used from within one. And that package is referred to by This Package.


 

(Update 9/08/2019, 18h00 : )

I think I now have a slightly more precise hypothesis, as to what may have triggered this recent setback.

(Hypothesis Scrubbed)


 

I should also mention that, when I install ‘LXDE’, I differentiate between two forms of it:

  1. A minimal install that can be launched, just through a user-process,
  2. A full-featured install that also depends on ‘gvfs’, and that offers features such as a working Trash Bin, as well as SAMBA Browsing…

Because I don’t think that ‘gvfs’ daemons will run properly without Session-Management, before the Desktop Manager is launched, on computers which are virtual, I tend to go with type (1) installs as described above. But for example, on the real computer I name ‘Klexel’, I have a variant of an LXDE install which I described as (2) above.

What UserLAnd originally tried to give me was a type (2) install, while what I now have is a type (1) install.

It would make perfect sense if the management of ‘gvfs’ daemons also required ‘systemd’.

Note: The type (1) LXDE Install above, could also correspond approximately to what the Debian ‘lxde-core’ meta-package pulls in, while my type (2) Install could correspond approximately to what the Debian ‘lxde’ meta-package pulls in.


 

1:)

There exists a way to carry out ‘apt-get’ operations, such as ‘install’ and ‘upgrade’, which are rumoured to bypass configuration, and they go as follows:

 


$ export DEBIAN_FRONTEND=noninteractive
$ sudo apt-get -y upgrade

 

Note: These settings can lead to brain-dead decisions being made for the user, such as to initialize databases with empty passwords, etc. But I now believe that this is what the UserLAnd script uses, especially when being used as a recovery tool / crutch. Also, in addition to the ‘-y’ flag, the ‘-f’ flag could have been used, to try to fix broken operations or packages…

 

AFAICT, Because my package-manager is set automatically to install Recommends, I could give one command that would restore everything that I had before the setback:

 


$ sudo apt-get install lxde gvfs-backends

 

But because I think I’d be installing packages that won’t work 100%, I think I’ll skip it for now.


 

(Update 9/09/2019, 16h15 : )

Just as a reminder:

What I did removed numerous packages, some of which I have not yet identified, that represent services which run in the background of real computers, but which must be launched from ‘systemd’, which in turn must run as ‘root’. This includes the Session-Management, that users go through in order to log in to their Desktop-Managers. Hence, without these packages, it would become impossible to log back in to the computer.

However, on my Android tablet, the entire Linux System is a Guest-System, that launches from a single user-process, as part of a VNC Session. In fact, because this Guest System is running in a ‘proot’, it cannot differentiate any process’s ownership, between different user-ids. Even if I give the command ‘su’ or ‘sudo’ here, the result is a process that still belongs to the same user-id.

Therefore, what was a critically important part of real computers, has turned into a feature that won’t work properly. And this is also why I don’t feel any loss over other daemons, that I may no longer have installed, that would need to be launched as ‘parallel processes, belonging to system user-ids’.

Yet, this Guest System still runs fine on my tablet, which is the Host System.

Dirk

 

Print Friendly, PDF & Email

One thought on “Major Problem when Upgrading a UserLAnd Linux Guest System via ‘apt-get’.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.