I have one of those Chromebooks, which allow a Linux subsystem to be installed, that subsystem being referred to in the Google world as “Crostini”. It takes the form of a Virtual Machine, which mounts a Container. That container provides the logical hard drive of the VM’s Guest System. What Google had done at some point in the past was, to install Debian 9 / Stretch as the Linux version, in a simplified, automated way. But, because Debian Stretch is being replaced by Debian 10 / Buster, the option also exists, to upgrade the Linux Guest System to Buster. Only, while the option to do so manually was always available to knowledgeable users, with the recent Update of ChromeOS, Google insists that the user perform the upgrade, and provides ‘an easy script’ to do so. The user is prompted to click on something in his ChromeOS settings panel.
What happened to me, and what may also happen to my readers is, that this script crashes, and leaves the user with a ChromeOS window, that has a big red symbol displayed, to indicate that the upgrade failed. I failed to take a screen-shot of what this looks like. The button to offer the upgrade again, is thankfully taken away at that point. But, if he or she reaches that point, the user will need to decide what to do next, out of essentially two options:
- Delete the Linux Container, and set up a new one from scratch. In that case, everything that was installed to, or stored within Linux will be lost. Or,
- Try to complete the upgrade in spite of the failed script.
I chose to do the latter. The Linux O/S has its own method of performing such an upgrade. I would estimate that the reason for which the script crashed on me, might have been Google’s Expectation that my Linux Guest System might have 200-300 packages installed, when in fact I have a much more complete Linux system, with over 1000 packages installed, including services and other packages that ask for configuration options. At some point, the Google Script hangs, because the Linux O/S is asking an unexpected question. Also, while the easy button has a check-mark checked by default, to back up the Guest System’s files before performing the upgrade, I intentionally unchecked that, simply over the knowledge that I do not have sufficient storage on the Chromebook, to back up the Guest System.
I proceeded on the assumption, that what the Google script did first was, to change the contents of the file ‘/etc/apt/sources.list’, as well as of the directory ‘/etc/apt/sources.list.d’, to specify the new software sources, associated with Debian Buster as opposed to Debian Stretch. At that point, the Google script should also have set up, whatever it is that makes Crostini different from stock Linux. Only, once in the middle of the upgrade that follows, the Google script hanged.
(Updated 10/25/2020, 22h55… )
(As of 10/25/2020, 13h40: )
On those assumptions, all I really need to do was, open a Linux terminal in case one was not already open, and type in the following commands:
$ sudo su # apt-get dist-upgrade
In some cases, ‘
apt-get‘ can be replaced with ‘
apt‘ – especially, after the upgrade to Debian Buster – and, I did not need to give the command ‘
apt-get update‘ because presumably, the failed Google script had already given that command.
Aside from answering a few prompts, which the Google script had not expected, I really didn’t have to do anything else. However, the whole process took me 5 hours, and not the 30 minutes that the Google window had suggested it would take. On larger Linux installs, doing a dist-upgrade can take 6-12 hours. A so-called dist-upgrade must not be interrupted at any point in the process.
After the upgrade, I found that all the applications I tested, work as before, including the (updated) ‘TigerVNC server’, that actually allows me to create an LXDE desktop, which I can then access via a ChromeOS-provided VNC Viewer. However, there is one more detail which I should mention:
When I set up Linux systems, I often install packages in a careful way, that ‘pull in’ libraries belonging to unused desktop managers, such as ‘GNOME’, either on my Plasma 5 -based computer, or on an LXDE -based computer. I’m careful not actually to install GNOME.
Well, during a dist-upgrade, this habit of mine can bite me in the ass. A dist-upgrade can and will perform a full install of GNOME in that case. What this does is, maximize the amount of storage the container uses, with the danger being, that at some point the amount of storage available on the ChromeOS Host System, might no longer accommodate the grown container. This creates a ‘hump’ which I had to wait through, before reversing the problem. After I had cleared this hump, I performed the following commands:
# apt clean # sync # apt autoremove
Amazingly, the ‘autoremove’ command removed the unnecessary packages again, so that again, ‘GNOME’ is not installed.
If one ignores the amount of time this took, the process was as reliable and easy, as if I had just done a smaller update. However, as Linux systems become larger and more complex, a dist-upgrade may not work as easily for the reader. Yet, as long as like me, the reader only has 1000 packages or so in his Linux subsystem, there is a good chance that like me, he or she can simply rescue a failed dist-upgrade in this way.
The hardest part of a dist-upgrade is usually, to get all the repositories right, in the file ‘/etc/apt/sources.list’… The second hardest part of a dist-upgrade is usually, whatever customization the user did to his system prior to the dist-upgrade, and then, trying to make sure that customized features work afterwards. As ingenious as the Linux dist-upgrade process is, it cannot take into account, what the user may have done, outside the route of the package manager. Out-of-tree installs are most likely to break.
I did observe that the Google script had added sources first, that offer Crostini packages, where stock Linux would not have those.
Before the upgrade, my Linux container took up 9.2GB, while afterwards, it was taking up 11.3GB. I am assuming that ChromeOS can shrink this container, in addition to being able to grow it.
There is another fact which readers should be aware of, that can cause the update to seem to have failed, when in fact it may not have.
The way Linux is generally organized is, into a system directory tree and a user home directory tree. Software from the package manager is generally installed to the system directory tree, not the user home directory tree, the latter of which is usually left alone. During an upgrade, several applications are upgraded to newer versions, as it should be. But, the applications still store their settings per-user, in the user’s home directory tree.
This does not change if the Linux system is running as a Guest System.
In some cases, applications with higher version numbers become incompatible with the settings that the previous version saved per-user. If a single application no longer seems to work, then one thing to do would be, either to delete or rename its per-user settings file – which could also be a sub-directory – and then to relaunch that application, with the understanding that it behaves from then on, as through ‘a first run’ was being carried out.
I needed to do this with ‘Bluefish’ specifically, before it would connect directly to my FTPS Server again.
I now have LibreOffice 6 where I previously had LibreOffice 5, and v6 works just fine, after translating its per-user settings automatically, to the version required.
(Update 10/25/2020, 22h55: )
A general note on using Bluefish to connect directly to an FTPS Server in this way:
The preferred way to do this would be such, that a coder does not need to retype the URL each time. But, in some cases, the only way I was able to connect to the server was, to open the ‘Seahorse’ application, unlock the FTPS password from there, close that application, open Bluefish, type in the URL once, acknowledge that an unverifyable certificate was being used by my (self-signed) server, close Bluefish again, open Bluefish a second time, and then, click on the URL in the History Pane.
A way to improve ‘connecting to FTPS URLs quickly’ is, once the FTPS Server’s contents are being displayed, pick a file at random, and create a bookmark, which is then a bookmark within one file, within an FTPS login. After that, even in a new session, after the FTPS Server password has been unlocked in Seahorse, it became possible for me just to open Bluefish once, navigate the Pane to its Bookmarks, click on the one bookmark, acknowledge the self-signed certificate, and I am logged on to the server, able to browse its files, and able to close that one file as well, without losing my login.
This just seems to be some weakness Bluefish has, in remembering FTPS URLs, and it has the weakness across Debian 9 and Debian 10 computers.