Gutsy Gibbon Upgrades

I've upgraded all four of my machines (two home machines and two work machines) from Feisty Fawn to Gutsy Gibbon. Two were pretty simple, the other two were tricky. One still doesn't have sound, which is really frustrating. I'm going to write up the gory details for my own benefit. It'll probably be boring for you. Sorry, blogs are like that ;-)

My laptop was the easiest. I don't keep anything on its hard drive. It's pretty much used as a thin client, so I could just about do a fresh install every time. I don't like to have to reconfigure stuff from scratch though, so I did the update-manager upgrade. It was quick, under two hours, and everything seems to be working fine. Oh, except my anti-aliased fonts on emacs. Those went away for some reason. That happened on all the machines. I probably just need to add back in the right repository for that.

The kids' machine at home had a small hiccup. It's an older celery-on machine and I'm running the Xubuntu desktop. It also has two 80 GB hard drives that I have in a RAID 0 configuration, for speed (oh yeah!). The upgrade had no problems with the RAID setup, but partway through update-manager configuring all the new packages, the screensaver came on and locked the screen, and for some reason it would not take my password. I had to ctrl-alt-1, log in, and kill xscreensaver. That killed X too though, and I had to manually use dpkg --configure -a to finish the upgrade. Everything seems fine now though.

My desktop at work was a chore. It probably has a fairly non-standard setup for Ubuntu: nfs mounted home directory, nis authentication, and a whole bunch of automounted nfs directories, and dual displays. I kept getting an error about packages not being authenticated for some reason. I thought it had something to do with our proxy, or maybe the repositories were overloaded whenever I tried and I just couldn't get things downloaded properly. I tried using the alternative install CD to do the upgrade instead of the regular update-manager process, but I either had the same authentication errors, or a strange message about not being able to calculate the upgrade. I tried putting our web proxy in /etc/apt/apt/conf.d, I tried setting the proxy under System-> Preferences-> NetworkProxy, but what finally worked was setting the http_proxy environment variable in a terminal and then running update-manager from that terminal. It was weird.

I left it downloading packages and went home for the night. When I came back the next morning the screens were black and the keyboard lights were flashing. I finally use magic keys to reboot it. X wouldn't come up, so I ctrl-alt-1ed and logged in (as a local user, nis wasn't working either). I did the same dpkg --configure -a that I had to do in the kiddos laptop and that ran for a while. At some point X started and the keyboard lights flashed again. Another reboot, more dpkg, and I got to a point where I encountered the device-mapper bug. I rebooted with magic keys again, but I booted an older kernel, removed evms as prescribed, and rebooted (nicely this time) again. I was finally able to get all the way through configuring all the packages, but it said it couldn't configure partially installed packages: acpid, ubuntu-desktop, powermanagement-interface, and acpi-support. I did an aptitude remove of all of those, and then an aptitude install to get them back, and finally everything seemed to be working. I did another aptitude update and aptitude full-upgrade just to make sure, rebooted, and now everything seems to be working (except my emacs fonts, dang it!). Phew!

Home desktop system. Everything seemed to go smoothly during the upgrade, however my sound didn't work when it was all said and done. There was some other weirdness due to an odd repository that I had added, but that was easy to fix. The sound problem however has not been easy. It appears to be a known problem. See this and this and this. Yes, lspci shows that I have this audio hardware:


00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

I tried the module-assistant steps and my audio still doesn't work. Grrr. Ubuntu, you've been so good to me for so long. Why now? Why something so basic as sound?

Comments

Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use
Read more

Git Rebase Explained

Image
Introduction Rebase is a helpful git command that can be used to turn a branchy two-headed version history into an easy to follow linear one. A linear history is much easier for a human eye to follow and a human brain to understand. Rebase is a very safe command to use, despite some fear that people have about it. This post should explain how rebase works and clear up any misunderstandings about it. Rebase Basics The short summary of rebase is that it cuts commits out of the git history and reconnects them somewhere else. Let's say the common scenario comes up: you commit a change to the main branch of a repository, you then run  git fetch , and in come a couple changes that other people made on the main branch. If your commit is version 46f and the others that just came in on the fetch are versions ef9 and 4a2, your version history might look like this: The main branch now has two heads, 46f and 4a2. You can run  git rebase  to disconnect your commit from version d88 and connect i
Read more