Monthly Archives: March 2008

Ubuntu crapping out on me (crypt on raid)

Shocker. Installing Gutsy 64-bit now to replace Windows 2003 Server. The installer looked pretty good. I was impressed by the option to create software raid partitions and encrypted partitions. I thought to myself: it can’t be this easy.

Yeap, sadly, it wasn’t. Upon first boot, gutsy crapped out on me and dumped me into the rescue shell. The issue:

fsck.ext3: No such file or directory while trying to open /dev/mapper/md0_crypt
/dev/mapper/md0_crypt:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

This is precisely the same issue as this guy was seeing in debian:
dm-crypt on raid does not play nicely

Conclusion: at the moment crypt on raid doesn’t work in ubuntu/debian releases. (You can probably make it work based on the article above.)

How to install java and set JAVA_HOME correctly in Ubuntu

Install Java 6 like this: (Note: the package is in multiverse)

sudo apt-get install sun-java6-jdk

Edit /etc/jvm, add this line to the top of the list: /usr/lib/jvm/java-6-sun

Thanks to the above step, the java executable will find the right version of java. You can confirm this with java -version. However, setting JAVA_HOME is a completely different matter.

These commands will detect set and verify JAVA_HOME:

. /usr/share/java-common/java-common.sh
eval $(jvm_config)
export JAVA_HOME
echo $JAVA_HOME

bazaar

What is Bazaar?

Bazaar is a distributed version control system that Just Works and adapts to the workflows you want to use.

I read about this a few months back, but I quickly dismissed the idea. I simply didn’t think it was feasible. Or useful to me. Until I read this on the Bazaar homepage:

The purpose of decentralized revision control systems is to break the chain between the developer and the server. This is done by moving the RCS data from the central server down to the developer. This is done by making a Bzr branch something that is like both a repository and a working tree.

Logically combining the RCS data with the working tree means that when you branch from somebody else, you end up with a repository of your own. That means you can commit in your branch without needing to ask for permission from the person you branched from. It’s almost as if you copied their SVN repository and made a SVN repository of your own.

Now I get it. It’s really cool. I remember the days when I used to do a lot of work offline (on the train). It was always difficult to group my changes into separate commits. Based on the VCS I was using at the time, I would develop tools to make changesets so that I can perform distinct commits when getting back online.

With Bazaar the problem simply doesn’t exist. When you check out a ‘branch’, your local copy becomes a repository by itself. You can commit to this local repository while offline. Then when you want to merge into your online project, you can push out your local commits. It’s brilliant.

http://bazaar-vcs.org/

How to synchronize subversion repositories with svnsync

I backup my svn repositories using svnadmin dump. From a dump like that a repository can be fully restored at any location via svnadmin load.

I’m playing with the idea of hosting some of my repositories on Google, but then I won’t be able to use svnadmin dump, my trusty backup method. However, snvsync looks promising as a suitable replacement.

1. Create a target repository with svnadmin create some_dir

2. Create a shell script at some_dir/hooks/pre-revprop-change that does nothing and just exits successfully (exit 0). Make sure the script is executable.

3. Initialize the target repository with svnsync init file:///abs_path/some_dir source_repo_url

4. Synchronize to target repository with svnsync sync file:///abs_path/some_dir. Notice that you don’t specify the source repository here anymore, that’s because the target is tied to the repository used in the initialization step.

Do not commit to the target repository. Always commit to the source, and after that run svnsync sync on the target, whenever needed.

If you want to mirror a Subversion repository to a complete different remote server, you can use a distributed version control software like Bazaar or Git. Here’s an article how I do this with Bazaar.