Write this down: Ubuntu 12.10, the late-year arrival from Canonical's six-month standard release factory, marks the first new release within the company's current long-term support cycle. Got it? Good, because it may be the best takeaway from the latest Ubuntu release, codenamed Quantal Quetzal. After that, it's a bit of a rocky ride.
The product's development lineage is important to note from more of a business/adoption side perspective. The release of Ubuntu 12.04 LTS in April was Canonical's fourth long-term support product and signaled the end of one full two-year development cycle. Quantal Quetzal is the first standard release on the road to pushing out Ubuntu 14.04 LTS in Spring 2014 (undoubtedly to be codenamed "Uber-rocking Unicorn" if the pattern holds), and it sets up themes and directions which will mature over the next two years.
Standard releases aren't terribly different from the bi-annual LTS products, though they tend to be slightly less conservative in code offerings. The Ubuntu development community lets off the brakes a little and sticks some shiny back in.
Ubuntu 12.10 is no exception, so make no mistake—there's some shiny goodness in this release. We'll get into what makes this a decent desktop and even more decent server release. But there's a little tarnish mixed in, too, and that makes Ubuntu 12.10 less special than previous editions.
Installer crazy
After writing about Linux for a little over a dozen years, I've come to the conclusion that writing about the installation of any Linux distribution should be banned from any review article. By now, Linux has gotten pretty good at installation on a variety of machines whether using thumb drives, discs, or the over-the-network approach. It's gotten so good that all you should have to say about installation is that you stick the media in, boot the machine, and a few steps later, you have a working example of distribution X.
That almost happened with Ubuntu 12.10. A showstopper bug at the very end of the install process on our first test machine broke the entire installation. A second test installation on VirtualBox crawled through the space-time continuum and ultimately failed. The only installations that performed flawlessly were a re-install on the first test machine (after fixing the boot problem that hung up the first go-around) and an express install that Parallels Desktop 8 for Mac ran through without a hitch.
To say this was a little surprising is an understatement. Leaving off the problem with VirtualBox for a moment (because that's not a typical use-case scenario), the fact Ubuntu could not be installed on a mainstream Lenovo machine due to a bootloader problem is a bit ridiculous.
This issue was wholly unexpected, that's for sure. The designers at Canonical have put together one darned fine installer in Ubiquity, with a slick and easy-to-follow process that experts can just zip through and beginners can step through without too much jargonism. We knew things were good when the Installation Type screen in Ubiquity spelled out in plain English what the system wanted to do with my hard drive.
On the virtual and physical installations, we basically opted to blow away our existing hard drives. But clicking the Something Else option delivered us to an easy-to-understand partitioning model that most intermediate users could follow if they wanted to set up a multi-boot system or a separate /home directory partition.
Everything in Ubiquity is about making Ubuntu easy to install. There's no package management at all, which can be either a boon or a curse. The only choices you get on what you want to install? You decide whether to add on the third-party proprietary software such as the Fluendo MP3 plugin that lets you play MPEG-3 files (which you should do unless you have a beef against such software). You also have a choice to update any packages that need it during the installation. This is a judgment call: Do it now or do it later. If you have the time, we'd recommend "now" so you have the most-secure packages on your system once installation is complete.
Another choice we suggest you make, especially if you are using a portable machine, is opting in when the installer asks if you want to use full-disk encryption. This is a new option in the 12.10 installation (previous releases forced you to go through extra steps or use the alternate install image in order to get full disk encryption working). This means you will have to set up and remember a machine-specific password, but for peace of mind, it's worth the effort. If your machine walks away, at least you won't have to worry too much about someone casually searching your system's files.
The inclusion of full-disk encryption as such an easy installation step is a pretty big deal for a Linux distribution. Its appearance in Ubuntu's Ubiquity installation is in no small part due to the efforts of the Electronic Frontier Foundation—the organization lobbied for full-disk encryption in Ubuntu back in May 2011.
That's assuming your installation is complete, mind you. After swimmingly pacing through the installation on a Lenovo G570 laptop that only had openSUSE 12.2 on it beforehand, things came crashing to a screeching halt when Ubiquity was unable to load bootloader on the main hard drive. That's the kind of problem common at the turn of the century, not in 2012 with arguably one of the most advanced Linux distros on the market. Yet there we were, staring at an error message telling us there would be no joy in Linuxville today.
This kind of error is aggravating—not just because it's outrageous to see it. To understand and fix this issue requires the kind of technological expertise that Ubiquity and the rest of Ubuntu's approach was trying to avoid in the first place.
It was not immediately clear what happened during our installation: the error message would not install on the default partition or any other partition we selected. The literature found on various community sites suggested the problem has to do with changes Windows 7 makes to the master boot record (these supposedly make Ubuntu's bootloader, GRUB, hard to load). In our case, it seems this problem also extended to machines on which Windows 7 has been completely replaced by other Linux distros, which can install themselves without problems. This bootloader issue is not a new problem, either: a quick search found many examples back to Ubuntu 11.04. This raises a third bone of contention—if this is not new, why hasn't it been fixed?
Fortunately, a fix is available. There's a great tool called boot-repair. When installed and run, it very quickly goes in and repairs the GRUB bootloader so that it can operate. To get it, boot to the Ubuntu LiveCD again and this time click "Try Ubuntu" rather than "Install Ubuntu."
In the Dash field, type Terminal and get ready to type these commands, pressing Enter after each line. (Because that's what every new Linux user should have to do, right?)
sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt-get update sudo apt-get install -y boot-repair boot-repair
When the first add-get-repository command runs, you will be prompted to say "yes" or "no" by the run sequence. Just type "Y" to keep the program going when asked. After running the last command, the Boot Repair application will open.
The hard part is over. Click the Recommended repair button in Boot Repair and let the application go through its process (it's just a few steps you can click through easily). Once completed, reboot the system and Ubuntu will start normally, bootloader intact.
While it is possible to use Ubuntu this way, extra files and language packs that would have normally been unloaded had Ubiquity been allowed to finish the job were still present on our initial installation. If you want everything ship-shape, your best bet is to step through the installation again.
Ideally, all of this rigmarole will be avoided and your Ubuntu 12.10 installation will run smoothly. Since it was so easy to use and did the trick, we would like to recommend that the functionality of boot-repair be incorporated into Ubiquity in future versions.
Clean-installing Ubuntu 12.10 on the test machine with no encryption and no software updates took 12:24. Grabbing all the software updates and applying full-disk encryption to the entire hard drive (including free space to really lock the disk down) took just a smidge longer, clocking in at 17:08. Your mileage will vary, of course, depending on how many updates Ubuntu has to get and install.
reader comments
117