Technology Tales

Trying out a new way to upgrade Linux Mint in situ while going from 17.3 to 18.1

There was a time when the only recommended way to upgrade Linux Mint from one version to another was to do a fresh installation with back-ups of data and a list of the installed applications created from a special tool.

Even so, it never stopped me doing my own style of in situ upgrade, though some might see that as a risky option. More often than not, that actually worked without causing major problems in a time when Linux Mint releases were more tightly tied to Ubuntu's own six-monthly cycle.

Linux Mint releases now align with Ubuntu's Long Term Support (LTS) editions. This means major changes occur only every two years, with minor releases in between. These minor updates are delivered through Linux Mint's Update Manager, making the process simple. Upgrades are not forced, so you can decide when to upgrade, as all main and interim versions receive the same extended support. The recommendation is to avoid upgrading unless something is broken on your installation.

For a number of reasons, I stuck with that advice by sticking on my main machine with Linux Mint 17.3 instead of upgrading to Linux Mint 18. The fact that I broke things on another machine using an older method of upgrading provided even more encouragement.

However, I subsequently discovered another means of upgrading between major versions of Linux Mint that had some endorsement from the project. There still are warnings about testing a live DVD version of Linux Mint on your PC first and backing up your data beforehand. Another task is ensuring that you are upgraded from a fully up-to-date Linux Mint 17.3 installation.

When you are ready, you can install mintupgrade using the following command:

sudo apt-get install mintupgrade

When that is installed, there is a sequence of tasks that you need to do. The first of these is to simulate an upgrade to test for the appearance of untoward messages and resolve them. Repeating any checking, until all is well, gets a recommendation. The command is as follows:

mintupgrade check

Once you are happy that the system is ready, the next step is to download the updated packages so they are on your machine ahead of their installation. Only then should you begin the upgrade process. The two commands that you need to execute are below:

mintupgrade download
mintupgrade upgrade

After these complete, restart your system. In my case, the process worked well, with only my PHP installation requiring attention. I resolved a clash between different versions of the scripting interpreter by removing the older one, as PHP 7 is best kept for testing. Apart from reinstalling VMware Player and upgrading from version 18 to 18.1, I had almost nothing else to do and experienced minimal disruption. This is fortunate as I rely heavily on my main PC. The alternative of a full installation would have left me sorting things out for several days afterwards because I use a customised selection of software.

Compressing a VirtualBox VDI file for a Linux guest

In a previous posting, I talked about compressing a virtual hard disk for a Windows guest system running in VirtualBox on a Linux system. Since then, I have needed to do the same for a Linux guest following some housekeeping. Because the Linux distribution used is Debian, the instructions are relevant to that and maybe its derivatives such as Ubuntu, Linux Mint and their like.

While there are other alternatives like dd, I am going to stick with a utility named zerofree to overwrite the newly freed up disk space with zeroes to aid compression later on in the process for this and the first step is to install it using the following command:

apt-get install zerofree

Once that has been completed, the next step is to unmount the relevant disk partition. Luckily for me, what I needed to compress was an area that I reserved for synchronisation with Dropbox. If it was the root area where the operating system files are kept, a live distro would be needed instead. In any event, the required command takes the following form, with the mount point being whatever it is on your system (/home, for instance):

sudo umount [mount point]

With the disk partition unmounted, zerofree can be run by issuing a command that looks like this:

zerofree -v /dev/sdxN

Above, the -v switch tells zerofree to display its progress and a continually updating percentage count tells you how it is going. The /dev/sdxN piece is generic with the x corresponding to the letter assigned to the disk on which the partition resides (a, b, c or whatever) and the N is the partition number (1, 2, 3 or whatever; before GPT, the maximum was 4). Putting all this together, we get an example like /dev/sdb2.

Once, that had completed, the next step is to shut down the VM and execute a command like the following on the host Linux system ([file location/file name] needs to be replaced with whatever applies on your system):

VBoxManage modifyhd [file location/file name].vdi --compact

With the zero filling in place, there was a lot of space released when I tried this. While it would be nice for dynamic virtual disks to reduce in size automatically, I accept that there may be data integrity risks with those, so the manual process will suffice for now. It has not been needed that often anyway.

Controlling clearance of /tmp on Linux systems

While some may view the behaviour in a less favourable, I always have liked the way that Linux can clear its /tmp directory every time the system is restarted. The setting for this is in /etc/default/rcS and the associated line looks something like:

TMPTIME=0

The value of 0 means that the directory is flushed completely every time the system is restarted, but there are other options. A setting of -1 makes the directory behave like any other one on the system, where any file deletions are manual affairs. Using other positive integer values like 7 will specify the number of days that a file can stay in /tmp before it is removed.

What brought me to this topic was the observation that my main Linux Mint system was accumulating files in /tmp and the cause was the commenting out of the TMPTIME=0 line in /etc/default/rcS. This is not the case on Ubuntu, and using that is how I got accustomed to automatic file removal from /tmp in the first place.

All of this discussion so far has pertained to PC's where systems are turned off or restarted regularly. Things are different for servers of course and I have seen tools like tmpreaper and tmpwatch being given a mention. As if to prove that there is more than one way to do anything on Linux, shell scripting and cron remain an ever present fallback.

Restoring GRUB for dual booting of Linux and Windows

Once you end up with Windows overwriting your master boot record (MBR), you have lost the ability to use GRUB. Therefore, it would be handy to get it back if you want to start up Linux again. Though the loss of GRUB from the MBR was a deliberate act of mine, I knew that I'd have to restore GRUB to get Linux working again. So, I have been addressing the situation with a Live DVD for the likes of Ubuntu or Linux Mint. Once one of those had loaded its copy of the distribution, issuing the following command in a terminal session gets things back again:

sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda

When there were error messages, I tried this one to see if I could get additional information:

sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda --recheck

Also, it is possible to mount a partition on the boot drive and use that in the command to restore GRUB. Here is the required combination:

sudo mount /dev/sda1 /mnt
sudo grub-install --root-directory=/mnt /dev/sda

Either of these will get GRUB working without a hitch, and they are far more snappy than downloading Boot-Repair and using that; I was doing that for a while until a feature on triple booting appeared in an issue of Linux User & Developer that reminded me of the more readily available option. Once, there was a need to manually add an entry for Windows 7 to the GRUB menu too and, with that instated, I was able to dual-boot Ubuntu and Windows using GRUB to select which one was to start for me. Since then, I have been able to dual boot Linux Mint and Windows 8.1, with GRUB finding the latter all by itself. Since your experiences too may show this variation, it's worth bearing in mind.

Turning off Apport crash reporting on Ubuntu

Last week, I kept getting a multitude of messages from Ubuntu's crash reporting tool, Apport. So many would appear at once on reaching the desktop session during system start-up that I actually downloaded an installation ISO disk image intending to perform a fresh installation to rid myself of the problem. In the end, it never came to that because another remedy produced the result that I needed.

Emptying /etc/crash was a start, but it did not do what I needed, and I disabled Apport altogether. This meant editing its configuration file, which is named apport and is found in /etc/default/. The following command should open it up in Gedit on supplying your password:

gksudo gedit /etc/default/apport

With the file opened, look for the line with enabled=1 and change this to enabled=0. Once that is done, restart Apport as follows:

sudo restart apport

This will need your account password before working, with any messages appearing afterwards. While I would not have done this for a real system problem, my Ubuntu GNOME installation was working smoothly, so it was the remedy I needed. The tool lets Ubuntu developers get information about application crashes, but it sends me to the Ubuntu Launchpad bug reporting website, which requires login details. This is enough to stop me continuing, making me wonder if developers could get what they need without this extra manual step. This would provide them with additional information and give us a more stable operating system in return.

Toggling the appearance or non-appearance of the Firefox session exit dialogue box

One thing that I notice with Firefox installations in both Ubuntu and Linux Mint is that a dialogue box appears when closing down the web browser asking whether to save the open session or if you want to have a fresh session the next time that you start it up. Initially, I was always in the latter camp, but there are times when I took advantage of that session saving feature for retaining any extra tabs containing websites to which I intend to return or editor sessions for any blog posts that I am still writing; sometimes, composing the latter can take a while.

To see where this setting is located, you need to open a new tab and type about:config in the browser's address bar. This leads to advanced browser settings, so you need to click OK, answering a warning message, before proceeding. Then, start looking for browser.showQuitWarning using the Search bar; it acts like a dynamic filter on screen entries until you get what you need. On Ubuntu and Linux Mint, the value is set to true but false is the default elsewhere; unlike Opera, Firefox generally does not save sessions by fault unless you tell it to that (at least, that has been my experience anyway). Setting true to false or vice versa will control the appearance or non-appearance of the dialogue box at browser session closure time.

Suppressing Update Notifier messages in Ubuntu GNOME 14.04

Even though I use only the command line for system updates, I still received system restart messages after kernel updates. Though these can be helpful, I prefer to restart my system on my own schedule, especially when running processes I don't want to interrupt.

In Ubuntu GNOME 13.10 and earlier, these messages didn't appear. I wanted to return to a notification-free experience. The Update Notifier application causes these messages, but removing it significantly impacts the system, making that approach impractical.

The application starts automatically at boot but doesn't appear in Startup Applications Preferences (launched via gnome-session-properties). This is because the NoDisplay flag in its autostart shortcut located in /etc/xdg/autostart/ is set to true. To make it visible, you need to set this flag to false.

The following command will reveal all hidden startup applications (note that the command is split across two lines for display purposes, and you may need to adjust quotes when executing it):

sudo sed -i 's/NoDisplay=true/NoDisplay=false/g'
/etc/xdg/autostart/*.desktop

The sed command changes NoDisplay=true to NoDisplay=false in all desktop files, revealing hidden entries in Startup Applications Preferences. This allows you to disable the Update Notifier. While deleting the desktop file would be more permanent, this solution works well as it stops restart notifications. Since I regularly update my system and shut down daily, updates are applied automatically, and everything functions properly.

Dropping back to a full screen terminal session from a desktop one in Linux

There are times when you might need to access a full screen terminal from a Linux graphical desktop. For example, I have needed this when installing Nvidia's graphics drivers on Ubuntu or Linux Mint. Another instance occurred on Arch Linux when a Cinnamon desktop update prevented me from opening a terminal window. The full screen command let me install an alternative terminal emulator, with Tech Drive-in's list proving helpful. Similar issues might need fixing on FreeBSD installations. These latter examples happened within VirtualBox, which has special requirements for accessing full screen command line sessions, which I'll explain later.

When running Linux on a physical PC, press CTRL + ALT + F1 to enter a full screen terminal and CTRL + ALT + F7 to return to the graphical desktop. In a Linux VirtualBox guest with a Linux host, these shortcuts affect the host instead. For the guest OS, use [Host Key] + F1 to enter a full screen terminal and [Host Key] + F7 to return to the graphical desktop. The default Host Key is the right CTRL key, unless you've changed it.

X sessions in GNOME and Cinnamon desktop environments support this functionality, but I can't confirm it works with alternatives like Wayland. Hopefully, this feature extends to other setups, as terminal sessions are occasionally needed for system recovery. Such mishaps are thankfully rare and should be virtually non-existent for most users.

Fixing garbled background images in GNOME Shell after upgrading to Ubuntu GNOME 14.04

On upgrading from Ubuntu GNOME 13.10 to Ubuntu GNOME 14.04, a few rough edges were to be noticed. One was the display of my chosen background image: it was garbled. Later, I discovered that there is a maximum width of 2560 px for background images in GNOME Shell these days and that things get messy beyond that.

In my case, the image width was around 6000 px, and I was used to it getting resized in GNOME Shell 3.8 and its predecessors. It appears that the functionality got removed after that, though, so the workaround of manual image resizing in the GIMP needed to be employed. Though having big images open in memory creates an additional overhead, not handling them very well at all looks like a bug caused by setting 2560 px as a maximum screen width for the GNOME Shell panel and the complete removal of Nautilus from desktop rendering duties. Let's hope that sense is seen with ever larger screen sizes and resolutions coming our way.

It's the sort of thing that did get me looking at adding on Cinnamon 2.2 for a while before setting background image scaling using the indispensable GNOME Tweak Tool was discovered. LinuxG.net has a useful tutorial on this for anyone with such an adventurous streak in them. For now though, I am OK with my set-up, but the GNOME project's focus on minimalism could affect us in other ways, so I can see why Clem Lefebvre started the Cinnamon one primarily for Linux Mint and the desktop environment is appearing elsewhere too. After all, Gedit lost its menu bar in GNOME 3.12 so it's just as well that we have alternatives.

Update 2014-05-06: It appears that the desktop image bug that afflicts GNOME Shell 3.10 got sorted for GNOME Shell 3.12. At least, that is the impression that an Antergos instance in a VirtualBox virtual machine gives me.

ERROR: Can't find the archive-keyring

When I recently did my usual system update for the stable version Ubuntu GNOME, there were some updates pertaining to apt and the process failed when I executed the following command:

sudo apt-get upgrade

Usefully, some messages were issued and here's a flavour:

Setting up apt (0.9.9.1~ubuntu3.1) ...
ERROR: Can't find the archive-keyring
Is the ubuntu-keyring package installed?
dpkg: error processing apt (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
apt
E: Sub-process /usr/bin/dpkg returned an error code (1)

Web searches indicated the issue was missing files in /usr/share/keyring, which I didn't delete. Since apt was disabled due to the missing keyring files, installing software for fixes was impossible. My solution was to copy the /usr/share/keyring files from an Ubuntu GNOME 14.04 virtual machine to the same location on my Ubuntu GNOME 13.10 host. For others without this setup, I've included these files in a zip file below. While other solutions like Y PPA were mentioned, they required prior installation, making them useless when tools like Synaptic were unavailable. I'd appreciate information on other fixes that don't involve reinstalling the operating system, potential causes for the file loss, and how to prevent it.

Ubuntu Keyrings