My initial source for the DRBD RPMs was the aTRPMs repository. However, I got frustrated with the tardiness with which the drbd kernel module packages got updated from them (up to several weeks after Fedora released a new kernel), so I decided to start building my own kernel modules when/if I needed them (i.e. whenever the Fedora developers decides to ship another Linux kernel for the distro version I’m running).

The instructions for building the sources are pretty straight-forward, and would/will work just fine if you’re only looking to build the drbd Kernel Module (drbd-km) for the kernel version that’s running at the time you run the build commands. However, since I – and, I suspect, most others  – use DRBD to mount file systems that have applications or services that rely on them at/during the boot process, waiting until after the new kernel is booted to build & install the DRBD kernel module just ain’t right. So decided to follow the instructions pertaining to building the DRBD kernel module against a kernel source tree (lower on the page I linked to above).

Unfortunately, that doesn’t work all that well for me….

# make km-rpm KDIR=/lib/modules/2.6.32.12-115.fc12.x86_64/build fails with:

[SNIP]

++ KDIR=/lib/modules/2.6.32.12-115.fc12.x86_64/build
++ scripts/get_uts_release.sh
+ test 2.6.32.12-115.fc12.x86_64 = 2.6.32.11-99.fc12.x86_64
error: Bad exit status from /var/tmp/rpm-tmp.OhAlII (%prep)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.OhAlII (%prep)
make: *** [km-rpm] Error 1

But, at least, the fix is pretty simple. Export the KVER environment variable set to the Kernel version you expect the rpm build script to check against:

# export KVER=2.6.32.12-115.fc12.x86_64

And “Bob’s yer uncle” as they say.

# ls -l rpmbuild/RPMS/x86_64/*

rpmbuild/RPMS/x86_64/drbd-km-2.6.32.12_115.fc12.x86_64-8.3.7-12.fc12.x86_64.rpm

I was looking to grow a shared (clustered) GFS2 file system I’m using for my web server and did the “usual” magic of extending the underlying logical volume (clvm managed), extend the disk label with fdisk and fsck -f the device so as to ensure there’s nothing latent in the metadata or data to cause my “grow” command to fail.

Then I issued

# gfs2_growfs /webroot

Which failed with the following error:

[snip] GFS2 rindex not found.  Please run gfs2_fsck

Well, that’s interesting….

Turns out an update to  GFS2 didn’t get reflected in gfs2_grow, so it’s looking in the wrong place for the rindex. The problem has been addressed upstreamand you can (I hope) expect to see the next version of the gfs2-utils (3.0.7) contain the fix.

UPDATE: The linked .rpm for Fedora 12 resolves the problem. The bug is a minor fix, thankfully, so I’d be surprised if a fixed version of the gfs2-utils package will not be included when they make the Cluster v3.0.7 packages available in the fedora-updates repository.

Thanks to the stellar help from the folks in the #linux-cluster channel on the Freenode IRC network! (fabbione, bob_home and abhi)