## 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… ## Klystron has a Severe Issue, when Suspending. In This Earlier Posting, I had written that my Linux laptop named ‘Klystron’ is able to suspend to RAM well and to Resume. As it turns out, after lengthy experimentation, this was not true. What that system tends to do, after having woken up from Sleep, is to have its clock set ahead by 68 hours. This is a Known Bug. And although there is a script which has been suggested, and which I have gotten to run, which tries to repair this damage in a crude way, that script failed to do so in a complete way. Even after I have set up This Script to run on Resume, after the first Suspend operation, everything seems to work again well. But after waking up for a second time, I found that the clock is set 136 hours ahead, instead of only being 68 hours ahead. And one reason fw this may happen, could be the fact that the script commands the system clock be set: date -R --date="-68 hours ago" This seems to have been a careless mistake, since to set the time to -68 Hours Ago, will actually set the time an additional 68 hours ahead. This can be verified, simply by running the above command from the command-line. And so I have edited this script, into one which must be compliant with SystemD-based Suspend, instead of with Upstart-based Sleep and Hibernate, and my script needs to be placed into ‘/lib/systemd/system-sleep‘ in order even to get run. And here it is:  #!/bin/bash # # fixing https://bbs.archlinux.org/viewtopic.php?id=173487 case "$1" in
pre)
date +%s > /tmp/suspend.log
;;
post)
was=cat /tmp/suspend.log
now=date +%s
# time shifts for 68 hours
if [ $now -gt expr$was + 244800 ]; then
date -s "date -R --date="68 hours ago""
fi
/etc/init.d/nmbd restart
;;
*)
;;
esac



The simple fact that my networking client could be connecting to the network, with false time information, can ‘discredit’ my client in the computerized mind of the router or server. And when a LAN client etc. is discredited, this can lead to connection problems…

For now, I am going to experiment further with trying to correct this. But if I run into further problems with this project, I am likely to abandon it.

Dirk