Sunday, October 16, 2016

Mint Upgrade Problem Solved

I decided to upgrade first my laptop (the canary in the mine shaft), then my desktop (assuming the canary lived), from Linux Mint 17.3 ("Rebecca") to 18.0 ("Sarah"). The "old school" approach would be to download the distribution to a CD/DVD, or create a bootable version on a USB stick, test it and then install it. Mint now provides a somewhat easier option, using a tool named mintupgrade. There's an upgrade tutorial on their web site, but I preferred to use a slightly modified approach suggested by a ZDNet writer, because it copies the voluminous terminal output to text files, making for easier searching (and preserving details that might be useful should a bug report need to be filed).

Unfortunately, earlier in the process I ran into a major hurdle. The first step is to run the Update Manager and verify that all level 1, 2 and 3 updates are installed. I did that, and my laptop appeared to be up to date. After installing mintupgrade, I ran 'mintupgrade check', and was told that in fact my laptop was not up to date, and so the upgrade could not proceed. Unfortunately, the check does not report which packages are not current.

Ignoring Einstein's definition of insanity, I ran Update Manager again (no change) and 'mintupgrade check' again (also no change). Next was a Google search that turned up other people with the same problem but no apparent solutions other than to go the traditional route (download the full installer, etc.). Something I read did cause me to run Update Manager and check whether I had excluded any packages from updating. (I had not.)

Fortunately, while I was mucking around with Update Manager, I decided to check Edit > Preferences > Levels. Lo and behold, the check box for level 3 "Safe updates" in the "Visible?" column was not selected. In other words, Update Manager (following a preference I don't recall ever setting) was not bothering to tell me about level 3 updates. Curiously, on my desktop the box was checked.

At any rate, I checked the box on the laptop, refreshed, and installed the rather lengthy list of level 3 updates of which I'd been unaware. After that, I was able to continue with the upgrade process. (After a warning from the upgrade script, I killed the screen saver, lest I find myself locked out of the user interface midway through the upgrade.) My laptop is not what you would call a gaming system (unless by "gaming" you mean "solitaire"), so I was expecting the upgrade to take some time. So I processed some email on my desktop, played a few (dozen) hands of solitaire, drove to the supermarket to pick up the week's groceries, returned home and stowed them, paid some bills ... and it was still cranking away, with no end in sight.

When it finally finished, and I rebooted, my laptop worked fine. I did notice one problem, though, which I probably should have anticipated. In the Software Sources application, all PPAs had been deleted (as well as anything in "Additional repositories"). Interestingly, the authentication keys for unofficial repositories were intact. Deleting the PPAs makes sense; they tend to be specific to a particular version of a distribution, and so would have to be updated. Still, having to replace them is a bit of a nuisance, and for future reference (meaning when I get around to doing this on my desktop) it will be easier if I make a list of them before upgrading.

Wednesday, October 12, 2016

DNS on Home WiFi

Like a lot of people, I have a home WiFi network, and I recently changed my Internet service provider. That required replacing my cable modem. Both the old and new modems provided a DHCP service that doled out local IP addresses to devices connecting to the home WiFi network. Both modems allowed me to designate static addresses for some devices. The old modem also provided a local name lookup service. The new modem does not.

What do I mean by "local name lookup service"? Each of my machines has a "host name", something like "MainPC", "Paul_laptop" etc. With the old modem, when I was logged into one machine and needed to connect remotely to another, I could just use the host name (e.g., working on laptop and connecting to "MainPC"), and the modem would find the correct IP address to use. With the new modem, "MainPC" just comes back as "host not found" or something similar. I can still get one machine to talk to another by typing in the IP address of the destination machine, but that's a PITA.

After some searching around, I found the answer to my problems here. Note that this only applies to Linux-based machines, which all mine are. In short, I needed to make sure the following four packages (and any dependencies) were installed:
  • avahi-daemon;
  • avahi-utils;
  • avahi-dnsconfd; and
  • avahi-discover.
For some reason, all my machines had the first two and none had the third and fourth. Now that they are installed, all I have to do is remember to qualify my machine names with the pseudo-domain "local" (e.g., "MainPC.local", "Paul_laptop.local"), and I can connect from one machine to another without fishing around for IP addresses.

I'll end with one last comment. Two of my machines run Linux Mint, and on them the name discovery service worked as soon as I installed the missing packages. One other machine runs a somewhat dated version of Mythbuntu, and that one had to be rebooted after installing the same two packages before the service worked. I'm not sure why, but I also don't really care. All's well that ends well, as some Brit said.