Technology Tales

Ensuring that Flatpak remains up to date on Linux Mint 19.2

The Flatpak concept offers a useful way of getting the latest version of software like LibreOffice or GIMP on Linux machines because repositories are managed conservatively when it comes to the versions of included software. Ubuntu has Snaps, which are similar in concept. Both options bundle dependencies with the packaged software so that its operation can use later versions of system libraries than what may be available with a particular distribution.

However, even Flatpak depends on what is available through the repositories for a distribution, as I found when a software update needed a version of the tool. The solution was to add PPA using the following command and agreeing to the prompts that arise (answering Y, in other words):

sudo add-apt-repository ppa:alexlarsson/flatpak

With the new PPA instated, the usual apt commands were used to update the Flatpak package and continue with the required updates. Since then, all has gone smoothly as expected.

Shared folders not automounting on an Ubuntu 18.04 guest in a VirtualBox virtual machine

Over the weekend, I finally got to resolve a problem that has affected Ubuntu 18.04 virtual machine for quite a while. The usual checks on Guest Additions installation and vboxsf group access assignment were performed but were not causing the issue. Also, no other VM (Windows (7 & 10) and Linux Mint Debian Edition) on the same Linux Mint 19.2 machine was experiencing the same issue. The latter observation made the problem intrinsic to the Ubuntu VM itself.

Because I install the Guest Additions software from the included virtual CD, I executed the following command to open the relevant file for editing:

sudo systemctl edit --full vboxadd-service

If I had installed virtualbox-guest-dkms and virtualbox-guest-utils from the Ubuntu repositories instead, then this would have been the command that I needed to execute instead of the above.

sudo systemctl edit --full virtualbox-guest-utils

Whichever configuration gets opened, the line that needs attention is the one beginning with "Conflicts" (line 6 in the file on my system). The required edit removes systemd-timesync.service from the list following the equals sign. It is worth checking that file paths include the correct version number for the Guest Additions software that is installed, in case this is not how things are. The only change that was needed on my Ubuntu VM was to the Conflicts line, and rebooting it got the Shared Folder automatically mounted under the /media directory as expected.

Lightening of desktop background images on Linux Mint Debian Edition running in Virtualbox

After a recent upgrade to Linux Mint Debian Edition 3 in a VirtualBox virtual machine that I had running its predecessor, I began to notice that background images were being loaded with more washed out or faded colours. This happened at startup, so selecting another background image worked as intended until the same thing happened to that after a system restart.

This problem is not new and has affected the Cinnamon desktop in the main Linux Mint variant (the one that is based on Ubuntu) and issuing the following command in a terminal session is a suggested solution:

gsettings set org.cinnamon.muffin background-transition fade-in

In my case, that solved the problem and the desktop background image display is as it should be since I executed the above. All it took was a change to a system setting.

Installing Firefox Developer Edition in Linux Mint

Having moved beyond the slow response and larger memory footprint of Firefox ESR, I am using Firefox Developer Edition in its place, even if it means living without a status bar at the bottom of the window. Hopefully, someone will create an equivalent of the old add-on bar extensions that worked before the release of Firefox Quantum.

Firefox Developer Edition may be pre-release software with some extras for web developers like being able to drill into an HTML element and see its properties, but I am finding it stable enough for everyday use. It is speedy too, which helps, and it has its own profile so it can co-exist on the same machine as regular releases of Firefox like its ESR and Quantum variants.

Installation takes a little added effort though and there are various options available. My chosen method involved Ubuntu Make. Installing this involves setting up a new PPA as the first step and the following commands added the software to my system:

sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-make
sudo apt-get update
sudo apt-get install ubuntu-make

With the above completed, it was simple to install Firefox Developer edition using the following command:

umake web firefox-dev

Where things got a bit more complicated was getting entries added to the Cinnamon Menu and Docky. While the former was sorted using the cinnamon-menu-editor command, the latter needed some tinkering with my firefox-developer.desktop file found in .local/share/applications/ within my user area to get the right icon shown. Discovering this took me into .gconf/apps/docky-2/Docky/Interface/DockPreferences/%gconf.xml where I found the location of the firefox-developer.desktop that needed changing. Once this was completed, there was nothing else to do from the operating system side.

Within Firefox itself, I opted to turn off warnings about password logins on non-HTTPS websites by going to about:config using the address bar, then looking for security.insecure_field_warning.contextual.enabled and changing its value from True to False. While some may decry this, there are some local websites on my machine that need attention at times. Otherwise, Firefox is installed with user access so I can update it as if it were a Windows or macOS application, and that is useful given that there are frequent new releases. All is going as I want it so far.

Upgrading avahi-dnsconfd on Ubuntu

This is how I got around a problem that occurred when I was updating a virtualised Ubuntu 16.04 instance that I have. My usual way to do this is using apt-get or apt from the command line and the process halted because a pre-removal script for the upgrade of avahi-dnsconf failed. The cause was its failure to disable the avahi daemon beforehand, so I needed to execute the following command before repeating the operation:

sudo systemctl disable avahi-daemon

Once the upgrade had completed, then it was time to re-enable the service using the following command:

sudo systemctl enable avahi-daemon

Ideally, this would be completed without such manual intervention. As it happens, there is a bug report for the unexpected behaviour. Hopefully, it will be sorted soon, but these steps will fix things for now.

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.