I’ve had a few nasty experiences this week with Linux and figured I’d vent here. Unlike my previous efforts with Linux From Scratch and Gentoo, my complaints this time around are related to upgrading Ubuntu.
Ubuntu 10.04 to 12.04: Save yourself the trouble
At this point the current Ubuntu LTS release (12.04) is my preferred distribution to work with: it has become widespread enough that troubleshooting and previous solutions online are easy to locate. In a professional capacity, I also maintain systems that are still on 8.04 LTS (supported until April 2013, so we have to be pretty aggressive about replacing them) or 10.04 LTS (good until April 2015).
I attempted to complete two upgrades from the 10.04 release this week to 12.04 – one 10.04 LTS “desktop” installation, and one 10.04 LTS headless server installation. Both were virtual machines running under VMWare ESXi, but neither had given me any trouble during normal use.
Canonical’s updater process (the wrapper around dist-upgrade) appears to be pretty slick; it gives you appropriate warnings, attempts to start a SSH daemon as a fallback mechanism and starts on its merry way to download the necessary packages to bring your system completely up to date. On my 10.04 desktop VM, the installer fell apart completely during the package replacement/removal/installation sequence. I was left with two nasty message boxes: one advising that my system was now in a broken state, and another that completely contained rectangular, unprintable characters.
To put it bluntly, I was not amused, but it wasn’t a critical system and I was content to replace it with a fresh 12.04 installation rather than waste additional time troubleshooting with apt or dpkg. Strike one for the upgrader.
At least the server came back up!
Next on the upgrade schedule was the 12.04 server VM. Install, package replacement and reboot went fine, but I had several custom PPAs installed to support development of XenonMKV (Github page) – specifically ppa:krull/deadsnakes to add Python 2.7 to Ubuntu 10.04.
Python 2.7 still worked when the server came back up, and all my usual tools of choice like SABnzbd+, SickBeard and CouchPotato were still functional.
For some reason, though, I’d gotten it into my head this evening to check out Mezzanine as a potential WordPress replacement. Mezzanine uses Django, a Python Web framework, and the list of supported features is pretty encompassing.
Sidebar: Django and mod_wsgi – complicated enough?
One of the most irritating things from a system administration point of view is getting Web applications to run in a standard server environment – typically a Linux base system and Apache or nginx to serve content. I suppose I’ve been spoiled with how easy it is to get PHP-based sites up and running these days in that configuration by adding an Apache module through apt. A lot of new Web app frameworks come with their own small webservers for development and testing, but generally their creators recommend that when you’re ready to put your site live, that the product run under a well-known Web or application server.
The Django folks recommend using mod_wsgi in their documentation, which in and of itself really just says “RTFM for mod_wsgi and then you’ll have a much better idea of how to do this.” I had to go poking around on Google for the installation article since there are some broken links, but okay, it’s an Apache module with a small bit of configuration (even though a simple walkthrough in the Django documentation would go a long way to making deployment easier.) This is where I ran into my dependency/PPA problem on Ubuntu 10.04.
I’ve suppose I’ve screwed the pooch…
Running the suggested command, I tried: sudo apt-get install libapache2-mod-wsgi and got the following
The following packages have unmet dependencies:
libapache2-mod-wsgi : Depends: libpython2.7 (>= 2.7) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
Backtracking, I then found out why the library wasn’t going to get installed:
The following packages have unmet dependencies:
libpython2.7 : Depends: python2.7 (= 2.7.3-0ubuntu3.1) but 2.7.3-2+lucid1 is to be installed
Aha! The Python installation from the PPA for Lucid – 10.04 – was installed and acting as the 2.7 package. Since the newly-upgraded Ubuntu 12.04 uses Python 2.7 as a dependency for a good portion of the default applications, I couldn’t just purge or uninstall it, and my attempts to force a reinstallation all ended in:
Reinstallation of python2.7 is not possible, since it cannot be downloaded.
Rebuild?
At this point it looks like I’ll have to rebuild the server VM as well, but if any readers have any bright ideas on fixing this dependency hell – please comment with your suggestions!
That sucks. Then again there’s a reason I don’t upgrade operating systems in place 😉
Is there no root option to tell Ubuntu to STFU and swap libraries? I suppose you could just download the deb file from the Ubuntu repo and manually extract it over top of the current PPA files… but that doesn’t sound like fun.
Yeah, I ordinarily wouldn’t do an in-place upgrade, but I’ve actually been reasonably successful with Debian (going from lenny to squeeze on a server). A complete desktop environment replacement, especially like the one from GNOME in 10.04 to Unity in 12.04, would definitely be trickier to do properly.
Turns out it wasn’t too terrible to follow your suggestion of installing directly from .deb packages. There were only three dependent files from the precise release and they were pretty easy to locate. All I had to do was install the following with dpkg -i from packages.ubuntu.com/precise:
* libexpat1_2.0.1-7.2ubuntu1.1_amd64.deb
* python2.7_2.7.3-0ubuntu3_amd64.deb
* python2.7-minimal_2.7.3-0ubuntu3_amd64.deb
Then I performed an sudo apt-get update; sudo apt-get upgrade which reinstalled the python2.7 packages from the “precise-updates” source. Finally, sudo apt-get install libapache2-mod-wsgi was able to pick up libpython2.7 (2.7.3-0ubuntu3.1) during the process.
Try changing to using the Main/United States package repository. I **was** using the United Kingdom, I did the change and this fixed my Python-dev ument package mismatch problems.
1. In ‘Ubuntu Software Center’ (USC) go tp the menu/tab ‘Edit => Software Sources’.
2. Change the ‘Download from’drop down value to ‘Main Server’ or a server in the United States (verified working, elsewhere).
3. Leave USC, the open ‘Update Manager’ from Ubuntu’s program menu, and ‘Check’ for software update (or issue ‘sudo apt-get update’ in a terminal window).
4. Update your software as you normally would, e.g. via ‘Update Manager’ or apt-get/aptitude in a terminal.
This worked for me, please see how you get on.
@Big Rich – sorry for the delayed reply, I didn’t see this comment when initially posted. In my case I did not have X.org installed (it was a server installation, with only CLI/SSH access available) so there was no menu or desktop to speak of.
I suspect you could accomplish the same thing by editing /etc/apt/sources.list and changing the HTTP/FTP URLs to point to the US repository, but theoretically packages on both mirrors should be the same. Perhaps it’s something in the “change source/apt-get update” process that triggers a refresh of the package cache, “forgetting” the broken ones.
Anyway, glad you found something that worked in a GUI environment. I ended up flattening and reinstalling 12.04 from scratch anyway due to a dead hard disk, but during the few months it was operational the .deb manual installation seemed to get me by fine.