Obsolete Your Idols

Maintain Low Tones -- Across Multiple Systems

Some combination of motherboards and CPUs on three separate systems at work went belly up this past week. One of them was mine. In an attempt to expedite getting back up and running, systems slated for some users got shifted to be available for the down users.

So the plus is that I have a faster CPU, more RAM and more disk, as I was able to migrate my disks into the new case and with some fiddling recover the data. The only complicated aspect of the operation was that I used the alternate CD ISO of Feisty Fawn and had some device-mapper issues trying to recognize the LVM partition I had been using. Overnight, without changing or updating anything, that issue went away. While that kind of spontaneous self-repair makes me nervous, I was just happy to recover my data.

But it wasn't that big of a deal because I use source control.

In fact, I use two systems.

For work output, the stuff I get paid for, I use the Perforce client since it's a free download for Linux and the choice of source control depot was made before I got there.

But I also use monotone for my personal configurations, ie, my home directory. I've got a script to deploy the pieces into place:

#!/bin/bash -x

cd ~/sharedhome

# deploy .files
for newfile in dot*; do
        oldfile=.${newfile:3}
        if [ ! -L ~/${oldfile} -o -d ~/${oldfile} ]; then
                mv ~/$oldfile ~/${oldfile}.bak
        fi
        ln -sf ~/sharedhome/$newfile ~/$oldfile
done

# system executables
SYSPATH=/usr/local/bin
CRONPATH=/etc/cron.daily
for cronfile in cron*; do
        oldfile=${cronfile:4}
        if [ -f ${SYSPATH}/${oldfile} ]; then
                sudo mv ${SYSPATH}/${oldfile} ${SYSPATH}/${oldfile}.bak
        fi
        sudo ln -sf ~/sharedhome/${cronfile} ${SYSPATH}/${oldfile}
        if [ -f ${CRONPATH}/${oldfile} ]; then
                sudo rm ${CRONPATH}/${oldfile}
        fi
        sudo ln -sf ${SYSPATH}/${oldfile} ${CRONPATH}/${oldfile}
done

# personal executables
HOMEBINPATH=~/bin
cd ~/sharedhome/scripts
for binfile in *; do
        if [ ! -L ${HOMEBINPATH}/${binfile} ]; then
                mv ${HOMEBINPATH}/${binfile} ${HOMEBINPATH}/${binfile}.bak
        fi
    ln -sf ~/sharedhome/scripts/${binfile} ${HOMEBINPATH}/${binfile}
done

# ssh pieces
HOSTNAME=`hostname`
cd ~/.ssh/
for localpiece in *.${HOSTNAME}; do
    LOCALIZED=`basename $localpiece .${HOSTNAME}`
    ln -sf ~/.ssh/${localpiece} ~/.ssh/${LOCALIZED}
done

It takes some pains to make sure it won't trample over something I want to keep while still putting the things I expect to find in the appropriate places. It could probably be smarter but it's sufficient to my needs.

The monotone database is easily replicated. I use the sync over ssh mechanism to do so as you can see here in my collection of aliases. I got this concept from the O'Reilly Hacks books.

# dotbash_aliases

alias realias="${EDITOR} ~/.bash_aliases &&  source ~/.bash_aliases"

alias reperl='perl -de0'

alias gor='mount /mnt/thumb && ~/bin/tclkit ~/bin/gorilla && umount /mnt/thumb'

alias malias='sudo vi /etc/aliases && sudo newaliases'

alias p4i='p4 integrate -b $0 $1'

alias cshare='cd ~/sharedhome && mtn commit .' 

alias sshare='cd ~/sharedhome && mtn sync ssh://fool.manjusri.org/home/binder/monotone/manjusri-configs.mtn "*"'

alias ushare='cd ~/sharedhome && mtn update'

alias ducks='du -cks * |sort -rn |head -11'

alias scan='sudo iwlist eth1 scan'

alias wmii2='export DISPLAY=:0.1 && wmii'

alias cdburn='sudo cdrecord dev=ATAPI:0,1,0 -v '

alias devmono='cd ~/src/monotone && mtn pull && mtn update'

So that just leaves the stuff which is neither in perforce nor in monotone and that data isn't really interesting or vital. But as with any data threat, it's a cue to back up all of my existing data everywhere.

posted at 08:35 PST (-0800)     (comments disabled)   permanent link  

Everything is Downhill From Here

The group I run D&D for has entered the World's Largest Dungeon and I've finally succumbed to the itch to buy a book for 3.5 Edition after years of fierce resistance.

Also a series of small spending sprees to obtain Forgotten Realms books. I have a fascination with the world Greenwood made which I either can't or won't justify. Especially to you!

Speaking of spending money, my copy of War on Terror arrived this week. Guess I'll be taking it to the next board game playing opportunity I have.

posted at 22:51 PST (-0800)     (comments disabled)   permanent link  

Or is the World ... Rising?

Once upon a time I had a machine with a hard drive in it. It ran for a couple years, running Debian stable. I added a second and then a third [smaller] hard drive to it. At some point I decided I wanted to be more clever about these devices and so I converted the non-swap partitions to LVM physical volumes. That was pretty cool because now I could dynamically resize partitions as I had different file system usage patterns.

But something weird started happening. I went through a couple physical moves, a couple releases of Debian stable, and I couldn't seem to get any newer kernels to be visible to grub.

At one point, I moved to a new place, changed the network configuration, rebooted to re-cable things and when it came up, the network configuration had reverted. In sorting that out, I discovered that I had a file-system which was serving as both my root file-system AND as a physical volume under LVM. OOPS. But I got that sorted out and things went along more or less normally, other than the no new kernel thing, until yesterday.

When I upgraded my monotone client instance on the work laptop [you see, I store my home directory in revision control and deploy it on systems I work frequently with] and monotone being the dynamic and giddy project it is, this upgrade made for a protocol incompatibility with the 'repository' [pronounced: synchronized database] I keep on the quirky system. So in trying to update that instance of monotone to the same version, I faced a choice of: upgrading to Debian testing, upgrading to Debian unstable, building monotone from source, side-grading to Ubuntu 6.06 LTS.

The right answer was building from source.

What I did was the side-grade. Or at least I started it. Somewhere along the way, the lvm2 package upgrade preinst script failed. I re-fired the dist-upgrade a couple times, made some progress, "decided" [here, the word represents sort of a random coin flip of synapses which is similar to the way other people decide things but lacking the illusion they try to dress it up in of it being a rational process] to reboot the system to get the newer installed kernel in play to see if that unstuck the lvm2 upgrade.

Nope. In fact, it very rapidly became worse. Much worse. Booting still only showed the original kernel I've been running on for years. Booting it forced me into maintenance mode. Sometimes it resulted in a runaway init being killed. Oh, bad times.

Luckily I keep a copy of the sysrescuecd in the home. I booted up with it, took a look at what was going on and kept "looking" [here, this word means jotting things down on paper and doodling and staring off into space because while I'm not a visual person I do seem to observe better with paper at hand] until I finally got it. By which I mean, I found a command which I wouldn't have expected to need, which I had never used before, but which made clear the lvm2 problem I'd been having.

vgreduce.

vgreduce? Yes. Because I got to wondering if I was using all of the physical volumes, I remembered how one of my disk partitions had been doing double duty before, and I was thinking along the lines of maybe carving out a partition to be a proper non-LVM /boot and put my kernel stuff in there so I could keep an eye on it, since booting to an LVM /boot seemed to be a sort of sometimes hit but mostly miss proposition for me. So I ran vgreduce with the -t switch and, wouldn't you know it, there were three partitions not being used and, uh, there was one which was being used twice. OOPS. How'd that happen?

So I got that sorted out, rebooted and ... kernel panic. So back to the System Rescue CD boot, scope it out again, do some various tomfoolery with grub and then I realized I had committed the Classic Grub Blunder.

The first partition on the second hard drive seen by BIOS, as seen by grub? That's hd(1,0). Everyone knows that one. The first partition on the first drive? hd(0,0). Third partition, first drive? hd(0,3). BZZZZZT No. No, it's not. hd(0,3) points at the fourth partition. Which, in my instance, was a swap partition and had been since system creation. For years, the only reason it was booting at all was that I page out so rarely that enough of a kernel image was still written there by grub to bootstrap me up to the running kernel. So once I got that sorted out, reboot, see many exciting kernel choices, boot without error AND with network again AND the dist-upgrade completed. PHEW.

That's why vgreduce is my hero of the day. Because until I used that to untangle my very first attempt at an LVM configuration, I couldn't even see the deeper underlying grub issue.

posted at 21:19 PST (-0800)     (comments disabled)   permanent link