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.

A few more shell commands

Here are some Linux commands that I encountered in a feature article in the current issue of Linux User & Developer that I had not met before:

cd -

This returns you to the previous directory where you were before with having to go back through the folder hierarchy to get there and is handy if you are jumping around a file system and any other means is far from speedy.

lsb_release -a

It can be useful to uncover what version of a distro you have from the command line and the above works for distros as diverse as Linux Mint, Debian, Fedora (it automatically installs in Fedora 22 if it is not installed already, a more advanced approach than showing you the command like in Linux Mint or Ubuntu), openSUSE and Manjaro. These days, the version may not change too often, but it still is good to uncover what you have.

yum install fedora-upgrade

This one can be run either with sudo or in a root session started with su and it is specific to Fedora. The command performs an upgrade of the Fedora distro itself, and I wonder if the functionality has been ported to the dnf command that has taken over from yum. My experiences with that in Fedora 22 so far suggest that it should be the case, though I need to check that further with the VirtualBox VM that I have created.

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.

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.

Automatically enabling your network connection at startup on CentOS 7

CentOS 7's release sparked my curiosity, so I tried it in a VirtualBox virtual machine. It uses GNOME Shell in classic mode, making it feel similar to GNOME 2. One thing to note is that it requires at least VirtualBox version 4.3.14, or the Guest Additions kernel drivers won't compile. This might seem surprising when you learn it uses kernel version 3.10.x and GNOME Shell 3.8.4. Like Debian production releases, CentOS chooses established versions for stability, fitting its enterprise-focused user base. Despite this conservative approach, it still looks good, though trying to change the desktop background froze the machine. Otherwise, most things work well.

However, there are surprises, including one I noticed: network connectivity needed switching on every time the VM started. This occurs with the default installation and has been a known issue since at least CentOS 6. It's not difficult to fix once you know how.

What you need to do is look for the relevant configuration file in /etc/sysconfig/network-scripts/ and update that. Using the ifconfig command, I found that the name of the network interface. Usually, this is something like eth0, but it was enp0s3 in my case, so I had to look for a file named ifcfg-enp0s3 and edit that. The text that is sought is ONBOOT=no and that needs to become ONBOOT=yes for network connections to start automatically. To do something similar from the command line, CentOS had suggested the following:

sed -i -e 's@^ONBOOT="no@ONBOOT="yes@' ifcfg-enp0s3

This uses sed for an inline (and case-insensitive) edit of the file to change 'no' to 'yes' after accessing the /etc/sysconfig/network-scripts/ directory. I edited manually with Gedit, which also works. Note that file editing needs superuser privileges, so switch to root with the su command or use sudo.

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 Background Image Display in GNOME Shell 3.10

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.