Edgy to Feisty Horror

As mentioned previously, I upgraded my work machine to Feisty Fawn without much trouble, but waited on doing my home machine because I knew it would be a bit trickier. The reason is I run a family website from that machine. It's basically a blog built with Django and it uses a PostgreSQL database backend. It also has a photo gallery with tons of family photos. I would hate to lose either of those.

I had a bunch of free time last night, and I had backed up important stuff to some DVDs recently, so I decided to go for it. I clicked upgrade in the Update Manager and off it went. About then a good friend of mine called. We hadn't talked for a long time, and we had a lot to catch up on. Perfect. I let the install run while we chatted. It was taking a while to progress, but I didn't think too much of it. After we hung up and said goodbye, I started reading a book. It was finally to the configuration and setup part and occasionally asked me some questions. I was enjoying the book, and didn't notice for a while how long this was taking. It was taking a long time. I noticed finally that the time on the computer screen had stuck at 11:58 PM, but it was really about 1 AM. I panicked a bit and looked hard. Something called mdadm was taking forever to do something. I typed top and saw an acroread process hogging all the CPU. "Curse you, Adobe!" I thought to myself. I killed the process and all of a sudden the upgrade started flying. It finished in just a few more minutes. Wow, I wish I had caught that sooner.

Being late and night, and just wanting to get through it, I didn't pay too much attention to what packages it said it was uninstalling because they were obsolete. I already knew it would uninstall mod_python for some strange reason. After the install finished I aptituded that, but my django website still wouldn't run. The database was missing! PostgreSQL had been uninstalled, and my database completely wiped out, as far as I could tell. PHP was also uninstalled. I've upgraded this box from Breezy to Dapper, and from Dapper to Edgy without any problem, I don't know why it decided to nuke those packages, and my data with it this time. That is just so wrong, Ubuntu, and I hope you are reading this!

No big deal though, I figured. This is a home machine, nothing new had been added to the database today and it was automatically dumped to a file by a cron job last night. I'll just import that dump file found here:


$ ll all.dbs.out
-rw-r--r-- 1 bryan bryan          0 2007-05-09 01:14 all.dbs.out

In case you didn't catch that, the "0" right before the "2007-05-09" means the file is empty. Yes, my backup failed, because it happened automatically during the update.

I can't recall too many times in my life when I've felt the blood drain from my face, but this was one of them. Seems like they have all been related to stupid things that computers have tricked me into doing, like just now. I suppose that in the grand scheme of things, that says a lot about how blessed I am. To only have cause for that kind of panic from minor things like lost data is really pretty good. Now, the morning after, I can think of much worse things to have to be afraid of. But I wasn't thinking about the grand scheme of things right at that moment last night.

Actually, I must not have been completely oblivious to said scheme, because I didn't panic for too long. I have a backup on a DVD that isn't too out of date. Maybe the missing blog entries from that could be found in the Google cache or something. A quick search showed that, in fact, they could be found. Thank you, Google. That just rocks.

The website is still currently down. I have the backup DVDs at work, just in case, and I'll retrieve the database dump when I get there, and then re-create any lost blog entries from the Google cache. Hopefully I won't find anything else amiss.

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