Technology Tales

Sorting out sluggish start-up and shutdown times in Linux Mint 19

The Linux Mint team never forces users to upgrade to the latest version of their distribution, but curiosity often provides a strong enough impulse for me to do so. When I encounter rough edges, the wisdom of leaving things unchanged becomes apparent. Nevertheless, the process brings learning opportunities, which I am sharing in this post. It also allows me to collect various useful titbits that might help others.

Again, I went with the in-situ upgrade option, though the addition of the Timeshift backup tool means that it is less frowned upon than once would have been the case. It worked well too, apart from slow start-up and shutdown times, so I set about tracking down the causes on the two machines that I have running Linux Mint. As it happens, the cause was different on each machine.

On one PC, it was networking that holding up things. The cause was my specifying a fixed IP address in /etc/network/interfaces instead of using the Network Settings GUI tool. Resetting the configuration file back to its defaults and using the Cinnamon settings interface took away the delays. It was inspecting /var/log/boot.log that highlighted problem, so that is worth checking if I ever encounter slow start times again.

As I mentioned earlier, the second PC had a very different problem, though it also involved a configuration file. What had happened was that /etc/initramfs-tools/conf.d/resume contained the wrong UUID for my system's swap drive, so I was seeing messages like the following:

W: initramfs-tools configuration sets RESUME=UUID=<specified UUID for swap partition>
W: but no matching swap device is available.
I: The initramfs will attempt to resume from <specified file system location>
I: (UUID=<specified UUID for swap partition>)
I: Set the RESUME variable to override this.

Correcting the file and executing the following command resolved the issue by updating the affected initramfs image for all installed kernels and speeded up PC start-up times:

sudo update-initramfs -u -k all

Though it was not a cause of system sluggishness, I also sorted another message that I kept seeing during kernel updates and removals on both machines. This has been there for a while and causes warning messages about my system locale not being recognised. The problem has been described elsewhere as follows: /usr/share/initramfs-tools/hooks/root_locale is expecting to see individual locale directories in /usr/lib/locale, but locale-gen is configured to generate an archive file by default.  Issuing the following command sorted that:

sudo locale-gen --purge --no-archive

Following these, my new Linux Mint 19 installations have stabilised with more speedy start-up and shutdown times. That allows me to look at what is on Flathub to see what applications and if they get updated to the latest version on an ongoing basis. That may be a topic for another entry on here, but the applications that I have tried work well so far.

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.

Upgrading a 2012 Google Nexus 7 to Android 5.0

Today, I was lured into upgrading my 2012 Google (ASUS) Nexus 7 to the final version of Android 5.0 (also known as Lollipop) by an icon in the device's top panel. Initially, it felt as it was working OK but a certain sluggish could not be overlooked and there have been complaints about this with some questioning the sense of what Google has done. However, there would have been remarks about grandfathering the device if they had not left us to have the latest release of Android, so there was no victory either way. We humans are fickle creatures, and there is an example of exactly that in a well observed double-ended short story by the Irish writer Maura Laverty.

While my impressions of how the upgrade had lumbered the tablet had me wondering about replacing the thing with either an Apple iPad Mini 2 or a Google (HTC) Nexus 9, a much less expensive option came to mind: doing a full factory reset of the device using its recovery mode. Though that may sound drastic, much of what I had on there was in the cloud anyway, so there was nothing to lose. So these are the instructions from Google themselves and I will leave you to use them at your own risk:

1. If your tablet is on, turn it off.
2. Press and hold the Volume Down button, then press and hold the Power button at the same time until the tablet turns on. You'll see the word "Start" with an arrow around it.
3. Press the Volume Down button twice to highlight "Recovery mode".
4. Press the Power button to start Recovery mode. You'll see an image of an Android robot with a red exclamation mark and the words "No command."
5. While holding down the Power button, press the Volume Up button.
6. Use the volume buttons to scroll to "wipe data/factory reset," then press the Power button to select it.
7. Scroll down to "Yes - erase all user data," then press the Power button to select it.

Note: If your tablet becomes unresponsive at any point during these steps, you can restart it by holding down the Power button for several seconds.

Once that was completed and the tablet restarted, the set-up routine began and took around an hour to reinstate the various apps that had been lost by the rest. Much of that was down to the time taken for re-installation rather than that taken by the actual downloads themselves over a wired broadband connection. The wait was worth it because the Nexus 7 feels more responsive again. While there are times when little lags are noticeable, they are nothing next to the slowdown that I had witnessed before the rest. It might have been a better option than attempting to return to Android 4.4.4 using a factory image, which was another option that I was considering. So long as there is no deterioration in speed, the effort expended to do a reset will have been worthwhile.

Restoring the MBR for Windows 7

During my explorations of dual-booting of Windows 7 and Ubuntu 10.10, I ended up restoring the master boot record (MBR) so that Windows 7 could load again or to find out if it wouldn't start for me. The first hint that came to me when I went searching was the bootsect command, but this only updates the master boot code on the partition, so it did nothing for me. What got things going again was the bootrec command.

To use either of these, I needed to boot from a Windows 7 installation DVD. With my Toshiba Equium laptop, I needed to hold down the F12 key until I was presented with a menu that allowed me to choose from what drive I wanted to boot the machine, the DVD drive in this case. Then, the disk started and gave me a screen where I selected my location and moved to the next one where I selected the Repair option. After that, I got a screen where my Windows 7 installation was located. Once that was selected, I moved on to another screen from I started a command line session. Then, I could issue the commands that I needed.

bootsect /nt60 C:

This would repair the boot sector on the C: drive in a way that is compatible with BOOTMGR. Though this wasn't enough for me, it was something worth trying anyway in case there was some corruption.

bootrec /fixmbr
bootrec /fixboot

The first of these restores the MBR, and the second sorts out the boot sector on the system drive (where the Windows directory resides on your system). In the event, I ran both of these and Windows restarted again, proving that it had come through disk partition changes without a glitch, though CHKDISK did run in the process, but that's understandable. There's another option for those wanting to get back their boot menu, and here it is:

bootrec /rebuildbcd

Though I didn't need to do so, I ran that too, but later used EasyBCD to remove the boot menu from the start-up process because it was surplus to my requirements. That's a graphical tool that has gained something of a reputation since Microsoft dispensed with the boot.ini file that came with Windows XP for later versions of the operating system.

Manually adding an entry for Windows 7 to an Ubuntu GRUB2 menu

A recent endeavour of mine has been to set up a dual-booting arrangement on my Toshiba Equium laptop, with Ubuntu 10.10 and Windows 7 side by side on there. However, unlike the same attempt with my Asus Eee PC where Windows XP coexists with Ubuntu, there was no menu entry on the GRUB (I understand that Ubuntu has had version 2 of this since 9.04 though the internal version is of the form 1.9x; you can issue grub-install -v at the command line to find out what version you have on your system) menu afterwards. Thankfully, I eventually figured out how to do this and the process is shared here in a more coherent order than the one in which I discovered all the steps.

The first step is to edit /etc/grub.d/40_custom (using sudo) and add the following lines to the bottom of the file:

menuentry 'Windows 7' {
set root='(hd0,msdos2)'
chainloader +1
}

Since the location of the Windows installation can differ widely, I need to explain the "set root" line because (hd0,msdos2) refers to /dev/sda2 on my machine. More generally, hd0 (or /dev/sda elsewhere) refers to the first hard disk installed in any PC, with hd1 (or /dev/sdb elsewhere) being the second and so on. While I was expecting to see entries like (hd0,6) in /boot/grub/grub.cfg, what I saw were ones like (hd0,msdos6) instead with the number in the text after the comma being the partition identifier; 1 is the first (sda1), 2 (sda2) is the second and so on. The next line (staring with chainloader) tells GRUB to load the first sector of the Windows drive so that it can boot. After all that decoding, my final remark on what's above is a simple one: the text "Windows 7" is what will appear in the GRUB menu, so you can change this as you see fit.

After saving 40_custom, the next step is to issue the following command to update grub.cfg:

sudo update-grub2

Once that has done its business, then you can look into /boot/grub/grub.cfg to check that the text added into 40_custom has found its way in there. That is important because this is the file read by GRUB2 when it builds the menu that appears at start-up time. A system reboot will prove conclusively that the new entry has been added successfully. Then, there's the matter of selectively to see if Windows loads properly like it did for me, once I chose the correct disk partition for the menu entry, that is!

Booting from external drives

Sticking with older hardware may mean that you miss out on the possibilities offered by later kit, and being able to boot from external optical and hard disk drives was something of which I learned only recently. Like many things, a compatible motherboard and my enforced summer upgrade means that I have one with the requisite capabilities.

There is usually an external DVD drive attached to my main PC, so that allowed the prospect of a test. A bit of poking around in the BIOS settings for the Foxconn motherboard was sufficient to get it looking at the external drive at boot time. Popping in a CrunchBang Linux live DVD was all that was needed to prove that booting from a USB drive was a goer. That CrunchBang is a minimalist variant of Ubuntu helped for acceptable speed at system startup and afterwards.

Having lived off them while in home PC limbo, the temptation to test out the idea of installing an operating system on an external HD and booting from that is definitely there, though I think that I'll be keeping mine as backup drives for now. Still, there's nothing to stop me installing an operating system onto of them and giving that a whirl sometime. Of course, speed constraints mean that any use of such an arrangement would be occasional but, in the event of an emergency, such a setup could have its uses and tide you over for longer than a Live CD or DVD. Having the chance to poke around with an alternative operating system as it might exist on a real PC has its appeal too, and avoids the need for any partitioning and other chores that dual booting would require. After all, there's only so much testing that can be done in a virtual machine.