One of my dedicated servers was in bad need of major LVM surgery today. Since the rescue system delivered with the server by the housing provider suffers from lack of LVM support, I needed to pull a creative stunt with grub and grml to accomplish this.
The dedicated server rented from strato is the Box I tested in a different article. Installing the LVM-based Debian system via the LVM-less rescue system involved first installing without LVM in the partition which was originally supposed to be swap, booting the just installed system and using this temporary system to finally bootstrap the target.
I had originally planned to go this way again in case rescue should become necessary. Today, I checked first whether the provider supplied rescue system had improved in the mean time (which it hadn’t), and I didn’t feel like installing a new temporary system. Instead, I decided to go through a different route, using grml.
grml is extremely versatile regarding boot. All you need is to get the grml kernel to boot and point it towards the grml initrd, and the initrd automatically searches the available drives for the compressed file system image, mounts it and continues the boot process. This was the point where I hooked myself into grml. I put an ext3fs on the swap partition and copied the contents of a grml CD to that partition. After thinking a while about how to get ISOLINUX to boot this grml, I remembered that the disk already has grub installed, and decided to use grub to boot grml.
This was possible because the provider offers a serial console for the machine. If no serial console had been available, things would have been a lot harder since there would be no feedback and one would have to talk to grub via offline editing of menu.lst. Thanks to the serial console, things were a lot faster.
Booting grml via grub is actually easy. After finding out which partition grml is on (find /linux26) and setting this partition as root, all you need is “kernel /linux26 ramdisk_size=100000 init=/etc/init lang=us BOOT_IMAGE=grml console=ttyS0,57600n8”, “initrd /minirt26.gz” and finally “boot”.
The “57600” given on the kernel command line was actually the hardest part: Strato operates the serial console at unusual 57600 bps, and grml’s serial console feature starts mgetty with hard-coded 9600 bps. The rather frustrating symptom was that you can watch grml booting, with “Finished execution of main grml startup” as the last sign of life. Knowing that there is a login prompt waiting for you at the wrong baud rate.
After talking to Mika from the grml team for some minutes, we decided to take two “roads” to solve the issue. Mika hacked grml’s startup process to parse the baud rate to be used for mgetty from the kernel command line. Since I couldn’t wait for Mika’s fix, I used a grml.sh script to put a fixed mgetty.config over the file contained in grml. After fixing some stupid mistakes on my part, I finally received my grml login prompt and could start with the LVM surgery.
Grml is a perfect tool for such tasks since it is extremely flexible and not selective in which medium and partition types it can boot from. It has saved me a lot of grief today and has helped me in solving a difficult problem.
Oh, btw, pvmove --alloc anywhere can move a logical volume inside a pysical volume without the need of a temporary physical volume, and it is thus possible to “manually” defragment a physical volume in order to allow more clean resizing of logical values. While it is debateable whether this does really make sense, it satisfies my sense of order to have an LVM setup unfragmented.