loopback filesystems, grub, and debootstrap

Update May 1, 2006: I now organize this type of info here.

I’ve been playing with VMMs like Xen and VMWare and OSes like Linux. One thing that can consume a lot of time is repartitioning disks all the time to get the desired number and variety of guest operating systems. I don’t usually do things in these guest OSes which are bound by disk performance, so it makes sense for me to use loopback-mounted disk images. I don’t just want a partition-as-image though, I want a disk-as-image, complete with an MBR and potentially containing multiple partitions.

I’ve used others’ instructions on loopback filesystems, creating partitions on disk images, installing grub, and debootstrap to figure this stuff out, but I’m putting a reminder-to-self here.

This command (see partitions on disk images)will create a 2GB file called disk-image, with 4096 cylinders (it also has 16 heads and 63 sectors — not sure where those numbers come from):

dd if=/dev/zero of=/path/to/c.img bs=516096c count=4096

Use fdisk to create a partition (I only created one, things get more complicated w/ additional ones):

losetup /dev/loop0 disk.img
fdisk -u -C4096 -S63 -H16 /dev/loop0

Now we must unmount the whole image and then remount just our partition so we can format it (#blocks is the number of blocks listed in fdisk when it prints partition information:

losetup -d /dev/loop0
losetup -o32256 /dev/loop0 disk.img
mke2fs -b1024 /dev/loop0 #blocks
mount -t ext3 /dev/loop0 /mnt
mkdir /mnt/boot
mkdir /mnt/boot/grub
cp /boot/grub/* /mnt/boot/grub
umount /mnt

Now we want to unmount the loopback device and install the grub bootloader on the MBR of our virtual disk (grub is supposed to be able to handle giving it /dev/loop0 when the disk.img is mounted via the loopback system, but it gives me “error 22: no such partition”).

losetup -d /dev/loop0
grub --no-floppy
grub> device (hd0) disk.img
grub> geometry (hd0) 4096 16 63
grub> root (hd0,0)
grub> setup (hd0)

Mount the formatted partition and install a base Debian system on it:

mount -text3 -oloop=/dev/loop2,offset=32256 disk.img /mnt
/usr/sbin/debootstrap --arch i386 sarge /mnt http://http.us.debian.org/debian

chroot into the new system to complete the install:

LANG= chroot /mnt /bin/bash

vi /etc/fstab
mount -a
mount -t proc proc /proc
dpkg-reconfigure console-data
vi /etc/network/interfaces
vi /etc/resolv.conf
/usr/sbin/base-config new



I find myself wanting to set these things up all the time, and I never remember how.

Here is a little shellscript to setup NAT assuming eth0 connects to the real world and tun1 is my internal interface.

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

# Set up IP FORWARDing and Masquerading
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface tun1 -j ACCEPT

Here are the contents of /etc/dhcp3/dhcpd.conf (put there by Debian package dhcp3-server).

subnet netmask {
option subnet-mask;
option broadcast-address;
option routers;

I learned most of this from here.

Upgrading SVN from 1.1 to 1.2

I’m a fan of SVN, and I recently upgraded it on a server for which I am the pseudo-sysadmin. I received an error which many SVN users of the world seem to have received at one point or another following an upgrade:

Berkeley DB error while opening environment for filesystem [omitted by Jon]: DB_VERSION_MISMATCH: Database environment version mismatch svn: bdb: Program version 4.3 doesn’t match environment version

Exactly what I did is upgrade debian packages from:




Apparently what’s going on here is that the version of Berkeley DB upgraded from ? to 4.3, and automatic DB updates don’t just happen.

The SVN manual suggests running svnadmin recover [/path/to/repo], but that pukes out another hideous and terrifying error message.

svn: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: Program version 4.3 doesn’t match environment version svn: bdb: Skipping log file svnmail/db/log.0000002291: historic log version 8 svn: bdb: svnmail/db/log.0000002292: log file open failed: No such file or directory svn: bdb: PANIC: No such file or directory svn: bdb: DB_ENV->log_put: 2292: DB_RUNRECOVERY: Fatal error, run database recovery

The fine folks who created this page on raditha.com gave me a major clue: that error message can actually be ignored. Because I always live in fear of good resources I come to depend on going away, I copied the error messages from the raditha site to this one. If that turns out to be a problem, let me know and I’ll remove them.