Migrating a Laptop from Windows to Ubuntu
The old laptop of my wife was still running Windows Vista for a variety of reasons but not only did the support for that end but the laptop itself has become slow to a point that was unacceptable. Swapping in a SSD two years ago improved the performance back then to what one would expect but lately it spent hours with 100% usage of one of the cores in the Windows Update service with the only result of drowning the battery. I spent countless futile hours trying to reset that service and entering magic commands found in the Windows Support Centre and other semi respectable forums on the internet only to find out hours later that nothing had changed.
All in all, even though some functionality would not be available under GNU/Linux, there was no other way forward than to migrate it.
Ubuntu 17.04 Gnome
Once the important data had been backed up, installing Ubuntu Gnome took only a couple of minutes. As I realized, the ISO images downloadable from Ubuntu for installation are hybrid ISO images that can directly be written to a USB stick just with dd, so this saved some further time where I would have previously used "UNetbootin <http://unetbootin.github.io/>`_ to build the bootable USB stick.
The laptop booted without problems from the stick and the base system was quickly installed. Rebooting the laptop however was slower than I expected it to be. Ok, it was instantaneous compared to the previous Windows installation, but there were delays feeling like short hangs.
Checking the logs with journalctl after the system was up, kernel warnings quickly stood out that always started with "vblank wait timed out on crtc 1". Ok, so obviously the graphics driver has some problems that we need to take care of. First thing in such a situation is to check the output of lspci to find the graphics controller used in the system:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
Searching the web for problems with this card, I quickly encountered the following freedesktop bug report. Although it was first reported early in 2016, obviously the problem still persists as it turns out that it indeed was the same problem that I experienced. Somewhat into the bug report, one poster found a solution by disabling the unused S-Video output with a kernel command line switch. Trying it out was a matter of adding the string "video=SVIDEO-1:d" in /etc/default/grub at the correct place to make the line look like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=SVIDEO-1:d"
Having run sudo update-grub the next reboot performed as fast as I expected it to be. It is a pleasure to see how fast such an old laptop can run with a modern GNU/Linux system.
Basic Functional Check
All of the basic functions worked out of the box. Wireless LAN, audio, multi-media keys and screen back-light control all worked without any further problem. The one problem that I found was the laptop not going into suspend mode when closing the lid. As the power button worked fine for putting the laptop to sleep and the log files showed that systemd-logind sees the lid being closed, I figured it must be a configuration problem and postponed it for later.
Now it was time to restore the backups and restore the email functionality.
Admittedly, the experience of migrating the email setup with three email accounts and a lot of archived mail in different folders stunned me the most. Simply restoring the folder 8csj1ec2.default from the Windows installation into .thunderbird and adjusting the Path=... directive to point to that folder in .thunderbird/profiles.ini was all that was needed. Starting Thunderbird after this made it come up with all the mails and configuration and new mails poured in immediately.
A big round of applause to the Thunderbird team for making such a process that easy!
Suspend On Closing The Lid
Returning to the suspend problem a few days later, it took some time to find out how these things are supposed to be handled today. As it turns out, the system layer as represented by systemd is complemented by the desktop system that also wants a say in what to do as it has knowledge of the user preferences available in the GUI. As I already found out that systemd-logind saw the event but did not react, it was easy to figure out that the rest of the configuration actually inhibited systemd to act. Presumably Gnome should take care of this but somehow didn't.
With this knowledge, a simple change to logind.conf was all that was required to suspend the system on a lid close:
--- /etc/systemd/logind.conf.ORIG 2017-05-14 23:17:37.701874052 +0200 +++ /etc/systemd/logind.conf 2017-05-14 23:16:08.984917555 +0200 @@ -26,7 +26,7 @@ #PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no -#LidSwitchIgnoreInhibited=yes +LidSwitchIgnoreInhibited=yes #HoldoffTimeoutSec=30s #IdleAction=ignore #IdleActionSec=30min
Even though it was easy to migrate the laptop to GNU/Linux with Ubuntu, someone with less Linux experience may have just given up experiencing the hangs in the GUI. I really do wonder why this specific bug is not resolved by disabling the S-Video output per default. This way the normal user would get a working system to start with and only needs to take further action when trying to enable an advanced feature that is not even available on most systems rather then the blocking most people.
Ubuntu especially has certainly come a long way in terms of making GNU/Linux a more streamlined user experience, but I still would suggest having a Linux savvy girl in your neighbourhood when starting to use it.
The functionality not available in GNU/Linux like the proprietary control program for the sewing machine of my wife and other such obscure pieces of software now happily run in a fully licensed Windows 7 VM in Virtualbox. As this one can even be run over the network, it lives only on one central machine and can be used from any GNU/Linux client on the few occasions that it is needed.
The experience shows that way more time is spent in starting the VM from time to time letting it install the required updates than the time it is actually used for real work. Contributing to this is that every Virtualbox update on the host needs a "boot vm and install new guest additions" round trip adding to this pure overhead. Not counting the latter, in all honesty, I wonder how much human time was and is lost in performing such maintenance tasks on Windows systems. I bet the numbers are just mind boggling.