Updates and Upgrading To A Later Release Of Mythbuntu

Generally, you do not want allow automatic updates to be applied to your system. While a good idea for a desktop or laptop system that is talking to the outside world, updates to an appliance-like system can often be bad news. The update process is not smooth enough or considerate enough of the special MythTV environment to proceed without mishap. Quite often, updates will break device drivers used for network cards, the display and the TV encoders. Any of these kinds of problems could prevent your Mythbuntu system from performing its primary role of recording programs and/or viewing them. When you want to watch the latest episode of Gossip Girl but it turns out that the system only recorded dead air because of some ill-conceived update, you won't be happy.

We suggest doing updates under controlled circumstances, all at once. If there is a block of time when the system isn't doing any work (minimum 8 hours), that's the time to schedule minor updates like patches. For major updates like version upgrades, a minimum of 48 hours is more like it. The problem of finding a window when updates can be applied is exacerbated if the system to be updated is the master backend, since any other secondary backends will rely on it for the database. However, it is very important to find a decent-sized window in which to do the work, since you don't need any time pressures when you're trying to straighten out all of the screw-ups caused by the updates.

Meanwhile, if you are doing kernel updates or a complete system upgrade, prior to beginning the process (i.e. before your update window begins), if your system needs any special network interface drivers, pre-build them, following the instructions in the "NIC Drivers" section, above. You can do this step at any time so why not get it out of the way before the time pressure begins. Since updates or upgrades frequently break the network interface, copy the drivers needed, for the new kernel or each of the intermediate Mythbuntu versions used in the upgrade, onto the system disk now so you won't have to put them on a CD later on. You should put them in the directory where your other special system drivers are stored. We use a subdirectory for each version and name them according to the Mythbuntu release that they apply to. For example:

     Ubuntu-8.10
     Ubuntu-9.04
         .
         .
         .

Incidentally, when you upgrade to Mythbuntu 11.10, the display manager is switched from GDM to LightDM. Unfortunately, although a fresh install of Mythbuntu 11.10 works, the upgrade procedure does not. Instead of making the switch to LightDM seamlessly, GDM is left partially installed, LightDM is not installed properly, and your system is left in a state whereby the display manager won't come up on the primary display. In other words, you're screwed.

What does this mean for you? Well it means that you'd better have a working NIC, that is supported by the default NIC drivers, that are included in Ubuntu-11.10. And, you'd better make sure that the network connection is going to come up automatically, all by itself.

The best way to make this happen is to set the network connection to DHCP before you begin the upgrade. And make sure that SSH is installed, configured and turned on so that you can login. And, if you've got some kind of flake-oh NIC on the motherboard, that requires a special build of the NIC device driver, you should go get a "regular" NIC and plug it in. Make sure it all works by itself, when you reboot the machine.

Because, if you don't, you're going to need to figure out how to boot the standalone Knoppix disk and repair the broken config files when you brick your system. Or, you're going to have to work out how to carry out the repairs from the console on the primary display (press <Ctrl-Alt-F2>, or <Ctrl-Alt-F3>, or <Ctrl-Alt-F4>, or F5, or F6, or whatever works). In either case, the actual steps necessary to repair the system are outlined further on but it will be a lot easier if you can login from a remote system via SSH.

The first step, when doing updates or an upgrade, should be to take a copy of the MySQL database. This database contains all of the information about when recordings should be done, what was recorded, etc., etc. If you lose this database, you are really not going to be happy. Use whatever MySQL backup procedure you feel confident with to get a copy of the "mythconverg" database from /var/lib/mysql.

For upgrades, the second step should be to make an exact copy of the Mythbuntu system's hard drive. You should use a drive that is at least as big as the original drive and copy everything over. If you wish, now would be a good time to upgrade the drive's capacity too. The upgrade should be performed on the copy, not the original. This allows you to back off all of the upgrade changes in one easy step, should the upgrade fail. Believe us, we've had to do this several times so skipping this step should not be an option. You'll be sorry if you do.

It is not possible to upgrade a release of Mythbuntu more than one step at a time. So, for example, if your system is 8.04 and you wish to upgrade to 9.04, you must first upgrade to 8.10. Sorry, that's just the way it is. This becomes an especial pain in the butt if you've waited too long to do the upgrade and the online updates are no longer available and/or you've applied special drivers (particularly the NIC driver) to your system. We'll assume that's the case (if you don't anticipate a problem with the NIC driver, you can simply do online upgrades from the Upgrade Manager under the GUI or from the command line with dpkg).

Begin by downloading the "alternate" distribution ISOs for all of the intermediate versions of Mythbuntu between your current version and the version you wish to upgrade to. You can get the distro for the final version too, if the updates for it aren't available online. Burn all of the ISOs to DVDs.

Boot Mythbuntu using the copy of the system disk that you made above. Apply all of the available online updates to your current Mythbuntu version. Once you've done this (and you reboot), your network may stop working. Don't panic.

The upgrade to the next version of Mythbuntu can be done using the "alternate" distro, despite there being no connection to the Internet. Proceed as follows:

     Insert the CD into the CD/DVD drive of the computer to be upgraded.
     A dialog will be displayed offering you the opportunity to upgrade using that
     CD.
     Follow the on-screen instructions.
     If the upgrade dialog is not displayed for any reason, you may also run the
     following command using Alt+F2:
     sudo gksu "sh /cdrom/cdromupgrade"

Note that, if you used pcsk, as described in "Keeping MythBackend Up And Running", to keep the backend up and running, you may experience a hang during the last stages of the upgrade when the install script for Myth Backend tries to start the mythtv-backend service. If this is the case, open up the console window of the install (checkbox at bottom of install window) and press "Ctrl-C". This will bail out of that step and the install will complain that it didn't work. Don't worry, be happy.

You should be able to fix up the pcsk problem by reaiming the symlink at the original mythtv-backend and the rerunning the backend reconfigure script. Try this:

     sudo rm -f /etc/init.d/mythtv-backend
     sudo ln -s /etc/init.d/mythtv-backend.orig /etc/init.d/mythtv-backend
     sudo dpkg-reconfigure mythtv-database
     sudo rm -f /etc/init.d/mythtv-backend
     sudo ln -s /etc/init.d/mythtv-backend.pcsk /etc/init.d/mythtv-backend

If this doesn't work, you should run the Myth Backend configuration (from the System menu) application and check the basic database connection information under the General menu item. Usually, the IP address of the database server will have to be reentered, if any changes are necessary. You probably should use a specific IP address instead of "localhost". The rest of the configuration information is stored in the database and should not need to be updated.

Incidentally, you may want to do a diff against mythtv-backend.pcsk and mythtv-backend.dpkg-new to see if any of the changes that the upgrade wants to make are actually important.

After you've done the upgrade and rebooted, your network may still not be working. The first step in getting it to work may be to rip out the Network Manager (again) as described in "Networking Your Way" (above) and set up the network the way you really want it. Then, apply the proper, pre-built NIC driver, as described in "NIC Drivers" (above) for the release that you are at. This should get the network working again.

As we noted above, when you upgrade to Mythbuntu 11.10, the display manager is switched from GDM to LightDM and, unfortunately, the switch does not work. When you reboot your system after the upgrade, the if the primary display comes up and flashes continuously, here's what we did to fix the problem.

Either login via SSH from a remote terminal or switch to the console on the primary display (press <Ctrl-Alt-F2>, or <Ctrl-Alt-F3>, or <Ctrl-Alt-F4>, or F5, or F6, or whatever works). Then, do the following:

     su
     stop lightdm
     ps x | grep light
     You may have to do a "kill -9" if there are any lightdm processes still
       running.
     apt-get install --reinstall lightdm
     dpkg-reconfigure lightdm
     Choose lightdm as your greeter.
     apt-get remove unity-greeter
     cd /etc/lightdm
     rm -f unit-greeter.conf
     nano lightdm.conf

When the text editor displays the lightdm.conf file, edit it to look like this:

/etc/lightdm/lightdm.conf:

     [SeatDefaults]
     autologin-guest=false
     autologin-user=AUTOLOGINUSER
     autologin-user-timeout=0
     autologin-session=lightdm-autologin
     user-session=mythbuntu
     allow-guest=false
     greeter-session=lightdm-gtk-greeter

You need to replace "AUTOLOGINUSER" to the name of the user that is normally logged in when the system starts up. This may be the "mythtv" user or it may be the user that you defined (besides root) when the system was initially installed. After you've done that, save the file and carry on. If you are really worried about GDM still starting up (it shouldn't, but you never know) you can do either (or both) of these:

     su
     update-rc.d -f gdm remove
     mv /etc/init/gdm.conf /etc/init/gdm.conf.off

Another thing you can check is that default-display-manager file in the X11 directory is set to lightdm. It should look like this:

/etc/X11/default-display-manager:

     /usr/sbin/lightdm

At this point, you should be able to start lightdm and X-Windows will come up on your primary display. You will either see the desktop or, if MythTV is set to auto start, you'll see it starting up:

     su
     start lightdm

If this doesn't work, you may still need to repair any changes made to the xorg.conf file by the system upgrade. You can begin by trying automatic configuration:

     su
     stop lightdm
     Xorg -configure
     cd /etc/X11
     mv xorg.conf xorg.conf.backup
     mv /root/xorg.conf.new .
     start lightdm

You may need to tweak the configuration file that is generated by configure but it is supposed to match your hardware. If it doesn't (usually because X-Windows cannot probe the monitor to get the EDID), LightDM may not start. A Web page that describes how to fix the problem can be found here:

     http://taggedzi.com/blog/display/ubuntu-11-and-nvidia-173-woes

If worst comes to worst, we keep a generic xorg.conf file that we can use when configure fails. This file is for NVidia graphics chipsets. It ain't much but it may get you up and running:

/etc/X11/xorg.conf.workee:

     Section "Monitor"
         Identifier      "Configured Monitor"
     EndSection
     Section "Screen"
         Identifier      "Default Screen"
         Monitor         "Configured Monitor"
         Device          "Configured Video Device"
         DefaultDepth    24
     EndSection
     Section "Module"
         Load    "glx"
     EndSection
     Section "Device"
         Identifier      "Configured Video Device"
         Driver          "nvidia"
         Option          "NoLogo"  "True"
     EndSection

If you have a different chipset, you'll need to change the video device driver name.

A cycle of all of the steps, beginning with booting Mythbuntu and applying all of the available online updates, ensues. You apply the online updates to the current release to bring it up to snuff and then upgrade it to the next release. Once you've finally arrived at the release that you're trying to get to, move on to the next step.

The upgrade process usually wipes out proprietary device drivers, etc. The NIC driver will already have been installed in the prior steps. You should also fire up the Mythbuntu Config tool (from the System menu) and install any of the recommended proprietary device drivers (e.g. NVidia). However, if you built the latest NVidia driver from scratch because you have a display that is not recognized by the regular, proprietary device driver, you will need to reinstall it because the driver will have been compiled against a kernel that is no more (see, for example, the Newest NVidia Driver section, above).

If you installed any special drivers (e.g. the saa7134-dvb driver, as described in "AVerMedia A180 Capture Card", above), you may need to reinstall them. Follow the steps outlined in the appropriate sections elsewhere. And, note that the names of the various blacklist and config files in /etc/modprobe.d may have changed. The newer versions of Mythbuntu require that the blacklist and config files (except for "options") be suffixed with ".conf". So, beware that the names of the files used to blacklist your special drivers may have changed.

Another feature of the wiping-out-drivers philosophy is that the sound control settings that you very carefully set, using alsamixer, are often wiped out too. If you experience sound problems (e.g. reduced volume) after the upgrade, see the section on "Sound Problems" (above) for tips on how to fix those sound problems.

When you upgrade to a later release of Mythbuntu (i.e. >= 9.04), you should read the section above about "Update Manager -- Not Another Good Idea". Upon upgrading to the later release of Mythbuntu, you will probably find the new behavior of the Update Manager to be a real pain in the butt and want to consult this section about how to turn it off immediately.

Since you'll probably be installing and removing packages as you go, you may want to consult the "Useful Software" and "Useless and Annoying Software" sections to at least figure out how to add the Synaptics Package Manager and remove the Ubuntu Software Center. While you're at it, you might as well install the rest of the useful packages and remove the rest of the annoying packages. All of your previous efforts, in this respect, will have been tossed away during the system upgrade.

And, speaking of butt pain, you may discover that the setup of your desktop has been altered when you upgrade to a later release of Mythbuntu. The most noticeable "feature" will be the disappearance of the desktop toolbar. If this happens, or if you notice any other little infelicities on your desktop, when you upgrade, you should see the "Desktop Problems" section, above, for notes about what to do.

Another "feature" of later releases of Mythbuntu is that the halt and shutdown commands that are invoked by the Myth frontend have been replaced by a shell script that uses dbus to tell HAL that it should shutdown or reboot the system. Too baddy that it only works some of the time. You may want to proceed to the Utilities/Setup/General menu item in the frontend and page forward to the Miscellaneous page where you can set:

     Halt Command: halt
     Reboot Command: reboot

On the other hand, if you really like the concept of using dbus to tell HAL what to do, you should upgrade these two settings for the newly upgraded system, since they will be left as is from before. The new settings are:

     Halt Command: /usr/share/mythtv/myth-halt.sh
     Reboot Command: /usr/share/mythtv/myth-reboot.sh

As with all upgrades to Mythbuntu, the LIRC setup is wiped out so your remote control will no longer work. If you are lucky, your orginal files will be preserved and suffixed with "dpkg-old" or maybe just "old". You can then delete the new files, installed by the upgrade, and replace them by the dpkg-old or old files. Here's what to look at:

     /etc/init.d/lirc
     /etc/lirc/hardware.conf
     /etc/lirc/lircd.conf

The lircd.conf file is made up on the fly by the lirc service script so you can just delete the newly-installed version. The lircd.conf.dpkg-old file can just be deleted too. Meanwhile, you should replace the /etc/init.d/lirc file with the script shown above, and the /etc/lirc/hardware.conf file with the saved one that you found under hardware.conf.old or that you saved elsewhere or that you made up according to instructions above.

Any upgrades to Mythbuntu may cause the MythWeather package to be upgraded too. If this happens, you are likely to lose any changes to the weather information extraction scripts that you made. Consequently, if you've included the Current Conditions page on your Mythbuntu weather page and the extraction script hasn't yet been fixed or if you've added any custom weather information extraction scripts, you may have to go back and reinstall the scripts, as described in the MythWeather section (above).

You should check the mythtv-database script, if you've upgraded it to run daily instead of weekly, to ensure that it is still in the /etc/cron.daily directory. Also, recheck that the upgrade has not added a copy of this script back to the /etc/cron.weekly directory where it will conflict with the running of the script on a daily basis.

If you are mounting sharepoints to support a remote video server (as described below under "Mounting Shares Under Mythbuntu"), you may find that the mounts no longer work. The upgrade will probably leave /etc/fstab as it was so that the mounts are still found in fstab but they will fail because the utilities supplied by the smbfs package will be missing. The upgrade will have removed the smbfs package. Searching for "samba" in the package manager should yield a list. If smbfs is not installed, follow the steps described in "Mounting Shares Under Mythbuntu" to install it and get the mounts working.

Also, if you have any additional drives that were formatted with the XFS file system, and the XFS file system wasn't installed on the system drive, you will probably see a message about "a serious error" upon startup, as the system tries to mount these drives. You can choose to skip the error and then mount the drives later on, with no problems, like this:

     mount /mnt/sdb1

So, what's going on? Because the system drive isn't an XFS drive, the upgrade decided that there was no need to install the xfsprogs package. This package contains the fsck.xfs program which is needed to check XFS drives. Since it was missing, when fsck tried to invoke it to check the XFS drives at startup, the check failed and fsck decided that there was a serious error. However, there's nothing really wrong with the drives, which is why you can mount them later on. The solution is to reinstall the xfsprogs package, like this:

     apt-get install xfsprogs

If you set up UPS monitoring with NUT, it will probably no longer work after a release upgrade. In all probability, any changes to the udev rules will be wiped out by the upgrade, which will disallow NUT from taking control of the UPS devices as it should. Another clever trick of release upgrades is to wipe out changes you've made to startup scripts in /etc/init.d with something "better" or "smarter". You should go over the install instructions in the UPS Monitoring with NUT section (above) to make sure that UPS monitoring is still installed and working correctly.

After you've completed your upgrade and tested everything thoroughly, you should reboot all of the other secondary backends and frontends in your network, if they depend on the upgraded machine as a primary backend. Don't ask me why this is necessary but it is. Some things will appear to be working OK, before the reboot, but others (e.g. sharing encoders across the network) will not work. The reboot seems to cure all.