Fixing the things that broke when upgrading from Mint 18 to Mint 19

[dnl]

Thank you to those who continue to develop Linux Mint and the tools to help us upgrade to newer versions.

I just completed an upgrade from Mint 18.1 to Mint 19. The Mint team has provided wonderful tools to do the upgrade. Very clear instructions can be found here ===> https://community.linuxmint.com/tutorial/view/2416

Even with these tools, the process is more difficult than I had expected. It took more than full day to get everything working again -- a surprising amount of time because my system is not that complicated.

I decided to document my experience and share it with the community just in case it may help someone get through the upgrade with less frustration and angst than I experienced.

This is not intended to be a general guide; it is instead a description of what I did to get my particular system working after the upgrade.

The system I upgraded was Linux Mint 18.1 Cinnamon running on an Intel NUC7 that I use as a network storage server and media player. Storage is accessed via SAMBA shares and media is played by vlc and python programs I wrote that are controlled by an IR remote via lirc.

The following is a step-by-step description of the upgrade, the problems encountered and the solutions. The steps documented here either fix or avoid problems with a vnc server, lirc and vlc


STEP 1: Upgrade from Mint 18.1 to Mint 18.3

A) I backed up my system using a utility external to Linux. I did not use Timeshift. I used it once to restore another system (it has a boot manager with legacy BIOS booting) and it overwrote the master boot record. It took about an hour to recover from that problem. I don't expect I will ever use Timeshift again.

B) I applied all level 1-3 maintenance.

C) I removed a video driver (xserver-xorg-video-intel), which is not required for the upgrade, but is recommended to improve performance.

D) Using the Update Manager, I upgraded to ver 18.3. No problems were encountered. Everything went smoothly.


STEP 2: Preparing for the upgrade to Mint 19

A) This is the third time I have done an upgrade to ver 19 and I discovered a few changes that can be done now that will simplify things later. Those changes are:

• Removed vino (a VNC server). The vino graphical configuration editor is no longer available in Mint 19. I could have kept vino and continued to use it but it did not seem worth the effort. Good alternatives are available so I decided to remove it now.

• Removed lirc, lirc-x and liblirccliente0. It was difficult for me trying to get lirc to work again after the upgrade. I eventually had to uninstall it to get things working so I decided to remove it now. Surprisingly, this also removed vlc. This turned out to be helpful as explained below.

B) The Mint team's instructions include a check of which display manager is used and to change the choice of manager if needed. I discovered I was using the mdm manager so according to their instructions I installed lightdm and removed mdm.

C) After installing lightdm, autologin no longer worked. I found a lot of advice on how to get autologin working again but most of the advice was to edit a configuration file. A much better solution, I think, is to use a settings applet. Menu -> Settings -> Login Window; Users tab; enter the Username for automatic login. Done.

D) I backed up the system.


STEP 3: Doing the upgrade to Mint 19

A) The first step is to install mintupgrade.

B) Unlike the upgrade to Mint 18.3, the upgrade to Mint 19 requires that you configure Timeshift. In my limited experience with Linux and application installations, an invitation to backup is often given but a backup is not required. I was surprised and disappointed by this change; it reflects a "we know what is best for you" attitude that I have come to expect from Apple software developers. NOTE to Linux developers: PLEASE don't become like them.

Fortunately, the use of Timeshift can be avoided by running the following command:

Code: Select all

    sudo touch /etc/timeshift.json

C) Then I ran mintupgrade check and reviewed its output carefully to discover anything that might interfere with the upgrade or any changes that might affect my system adversely. I did not need to take any remedial steps or precautions.

D) I then performed the upgrade by running mintupgrade download followed by mintupgrade upgrade.

E) These two steps took a while. After they finished (all went well), I rebooted the system.

STEP 4: Fixing things that broke or changed

A) My system has an SSD and plenty of RAM. I had configured the system to swap less by making a change to /etc/sysctl.conf. That configuration file was replaced so I needed to make the change again by adding the line: vm.swappiness=1

B) I had a number of problems with lirc and an IR remote. Mint 19 and the kernel I installed behave very differently from what I had been running. I got lirc working again by doing the following:

(1) Installed ir-keytable. (Note that lirc is not installed at this point.)

(2) Ran the following to get the IR transceiver name, which is "ITE8708 CIR transceiver":

Code: Select all

    grep "^N:" | /proc/bus/input/devices

(3) Ran ir-keytable -t to get the codes from my remote. It is an RC6 remote but there are a few differences with the default RC6 keymap table that is installed with ir-keytable.

(4) Set up a modified key table for my remote:

Code: Select all

    sudo cp /lib/udev/rc_keymaps/rc6_mce /etc/rc_keymaps/my_RC6_key_map
    gksu xed /etc/rc_keymaps/my_RC6_key_map  (edit as desired)

(5) Set up an automatic load of this key table at boot by changing the rc-rc6-mce line as follows in /etc/rc_maps.cfg

Code: Select all

    *    rc-rc6-mce    my_RC6_key_map

(6) Installed lirc and lirc-x.

(7) Blocked IR signals from getting to X11. This required two changes:

• Created a rule for X11 to ignore the remote:

Code: Select all

    gksu xed /usr/share/X11/xorg.conf.d/10-mce-keyboard-disable.conf 
        # Disable CIR transceiver as an input device to X11
        Section "InputClass"
            Identifier  "CIR transceiver disabled as X11 input device"
            MatchProduct "ITE8708 CIR transceiver"
            Option      "Ignore" "on"
        EndSection

• Disabled lircd-uinput from forwarding IR signals back to the kernel:

Code: Select all

    sudo systemctl stop lircd-uinput.service
    sudo systemctl disable lircd-uinput.service

(8) I also needed to prevent the lirc irexec daemon from running as root:

Code: Select all

    sudo systemctl stop irexec.service
    sudo systemctl disable irexec.service

These changes got lirc working again as it had been working in Linux Mint 18.1.

C) Installed x11vnc (replacement for vino).

Code: Select all

    sudo apt-get install x11vnc
    sudo mkdir /etc/x11vnc
    sudo x11vnc --storepasswd /etc/x11vnc/x11vncpswd
    gksu /etc/x11vnc/x11vncpswd
        [Unit]
        Description=Start x11vnc at boot.
        After=multi-user.target display-manager.service
        [Service]
        Type=simple
        ExecStart=/usr/bin/x11vnc -auth guess -forever -noxdamage -repeat -rfbauth /etc/x11vnc/x11vncpswd -rfbport=5900 -shared
        Restart=always
        RestartSec=5
        [Install]
        WantedBy=multi-user.target
    sudo systemctl daemon-reload
    sudo systemctl enable x11vnc.service
    sudo systemctl start x11vnc.service

D) Recompiled all of my python programs. They had been compiled under version 3.5 but it appears version 3.6 is what you get when you run python3 in Mint 19.


PROBLEM AVOIDED:

After completing one of my previous attempts to upgrade, vlc could not open my media files. Apparently a different flavor of vlc is installed during the upgrade to Mint 19, which can be fixed by uninstalling vlc-nox and installing vlc. By removing vlc prior to the upgrade, this problem was avoided.


I hope these notes will be at least a small help to someone.

[catweazel]

I hope these notes will be at least a small help to someone.

A very thorough run-down. The issue is that upgrades between point releases, e.g. 19, 19.1, 19.2 etc, are usually trouble free. I wouldn't ever recommend an in-place upgrade between major releases, e.g. 17 to 18, or 18 to 19, because of all the potential issues, despite the best intentions of the author of the article.

A simple read of the article prior to performing the instructions at that source would have revealed the statement that "The upgrade overwrites files in /etc/ with default configuration files", and a read of the comments would have instilled an awful lot of caution by me rather than any confidence at all. A backup of treasured files and a clean install should always be preferred to upgrading between major releases. For the next time, I recommend that users make copious notes about the steps performed to do a clean installation. It usually takes much less time to follow the notes when they're needed than it does to fix a broken upgrade.

[karlchen]

I wouldn't ever recommend an in-place upgrade between major releases, e.g. 17 to 18, or 18 to 19, because of all the potential issues

We grow with the challenges that we face and master. ... Or we perish miserably.

[AndyMH]

For both 17 to 18 and 18 to 19 I did a clean install. I won't say it was painless, but a lot less hassle that trying to do an upgrade. Okay, it doesn't happen very often, but having a separate /home partition makes life a lot easier.

[dnl]

For the next time, I recommend that users make copious notes about the steps performed to do a clean installation. It usually takes much less time to follow the notes when they're needed than it does to fix a broken upgrade.

A good suggestion. I keep a text file on my desktop that has a very detailed log of my installation and subsequent changes, including the dates/times of backups. If I need to restore from a backup, I have a log that shows the changes I need to make (or avoid) to get my system to the state I want. I used that log of the 18.1 install to check what settings and configurations had been changed by the 19 upgrade process. That is how I discovered the swapiness parameter was lost.

I plan to do a clean install of 19.1 on a similar machine within the next few days. I will report on the difficulty of that vis-a-vis the upgrade.

[dnl]

Okay, it doesn't happen very often, but having a separate /home partition makes life a lot easier.

I am curious how having a separate /home partition makes things easier. I tried a separate /home partition once and I could not see any significant advantage. Applications write configuration parameters into the home partition so I don't think it can be considered truly independent of what is installed in the root partition.

I should add that I keep all of my documents and databases on a separate partition and have symbolic links from /home directories to directories on that partition. I guess I could accomplish about the same thing with carefully chosen mount points for different directories but what I am doing now seems simpler and easier to change if I want to.

In any case Andy, you make a point that I would like to understand better. I think I will post a question about this in another thread.

[hcentaur13]

/home is the home of any uinstalled user. That hold the home directory for each user, including some standard subdirectories. Having the content of /home outside the partition / holds makes sense because formatting / as needed by a restinstall lets any other partition unattached. Creating the mountpoint /home is enough to get back any user data in action.

It is its own partition that seperates user data from the system and makes it independant. It is the sense of having user data seperated from system to have it secure when something creashes the system partition without having the need to spend hours to backup user data to get / clean. Mounting makes any directory independant from its physical place. Logical you and the system sees no difference. A partition makes the content physical independant even as logical is no difference.

[arvy]

I am curious how having a separate /home partition makes things easier.

You might want to consider and comment on my alternative approach here. I find that it serves two purposes without double effort.

[dnl]

I plan to do a clean install of 19.1 on a similar machine within the next few days. I will report on the difficulty of that vis-a-vis the upgrade.

I completed the new install of 19.1 today. The new, clean install had fewer problems to solve (and an unexpected bonus) than the upgrade did; however, more work was needed to configure the system. Nearly all of these configurations (done in the previous system) were carried forward by the upgrade. It appears that the clean install and the upgrade took about the same amount of work.

Here are the differences:

1. I had no problems with lirc. What had taken most of a day to solve with the upgrade worked immediately after the new install.

2. I had no problems with VLC. It worked correctly without any need to uninstall/re-install.

3. Unexpected bonus: I had posted in another thread that I could not get Firefox to play DRM-protected content. I tried on several different systems without success. With this installation, it worked after enabling DRM playback. Here as in the other cases, the Widevine plugin was installed and active.

My conclusion is that this upgrade provided a mixed bag of benefits and problems and this probably is true for all upgrades from one major release to another. Given the fact that there is little if any reduction in work doing an upgrade, I think the suggestions given by others in this thread not to do such major upgrades appear to be good suggestions.