Creating a super-pendrive


Its been really long since I blogged. Before going ahead, want to tell you that will be posting my endeavours on running virtual machines soon.

This, however, is my experience/guide for creating a super pen drive (a.k.a. a usb disk that if booted from presents a grub menu with options – GParted, Fedora, .. and any other linux distro hopefully, and has Fedora persistence, and has a spare partition too for you to use it as a normal pen drive).

It wasn’t as straight forward as I thought (like… all other things).


  1. Decide the partitioning layout and partition the pen drive.
  2. Install grub on one partition
  3. Install GParted on another
  4. Install Fedora on another
  5. Install grub again on the partition in step 2 :P, and setup grub.conf
  6. Sit back, and enjoy (may need to crouch forward in some cases.. )

A super neat trick:

To check at any time how you pen drive would behave if you boot from it, use the command : qemu -hda /dev/sdb -m 256 -vga std

This command reduced my research time to one third.

1) Decide the partitioning layout

I used GParted on my Fedora installation (on my harddisk) to set up the partition of the pen drive.

2) Install grub on one partition

Make sure you manually mount the grub partition. The /media/something folder in which it gets mounted automatically gave me some trouble. So unmounted it from there, and mounted /dev/sdb5 to /mnt/usbgrub

grub-install –no-floppy –root-directory=/mnt/usbgrub/ /dev/sdb

3) Install GParted on another

Use UNetbootin for GParted

4) Install Fedora on another

Need to make sure that usb disk is ext3 before doing this. When I did this on a vfat disk, I got an “error 22” when trying to boot from the usb disk.

Use liveusb-creator or live-iso-to-disk for Fedora.

Persistence is buggy according to so instead, a better solution is to directly install fedora on the pen drive on a separate partition, like in

5) Install grub again on the partition in step 2 :P, and setup grub.conf

mount /dev/sdb5 /mnt/usbgrub/

grub-install –no-floppy –root-directory=usbgrub/ /dev/sdb

Now, to setup the grub menu:

cd /mnt/usbgrub/boot/grub/

cp /boot/grub/grub.conf .

cp /boot/grub/splash.xpm.gz .

gedit grub.conf

# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,1)
#          kernel /vmlinuz-version ro root=/dev/mapper/VGSahil-LVRoot
#          initrd /initrd-version.img
title Fedora (
root (hd1,1)
kernel /vmlinuz- ro root=/dev/mapper/VGSahil-LVRoot rhgb quiet
initrd /initrd-

title GParted Live
root (hd0,5)
kernel /live/vmlinuz1 boot=live union=aufs    noswap noprompt acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp ip=frommedia vga=normal
initrd /live/initrd1.img

title Omega 11 Live
root (hd0,6)
kernel /syslinux/vmlinuz0 root=/dev/sdb7  rw liveimg quiet  rhgb
initrd /syslinux/initrd0.img

Digikam Caveats – things to make sure using Digikam

I have been bitten. And so I post this in the hope that some needy soul finds this before he/she/it gets bitten too.

Problem: Digikam saves image tags (ratings/captions that you spend hours editing) in its internal database. When you switch to a newer linux version, lose this information – unless you are careful enough to copy over the digikam.db4 file – which I was. The second problem is that if you move around or copy your files using a file browser, you lose this information ( !!!! ), and digikam doesn’t allow copy of albums (!!).


  1. Specify the location of your digikam.db4 file as the root directory of you photo library. This way, when you move your library, you have the digikam database with you.This can be configured through digikam Configuration > Collections.
  2. The most important step (which digikam should have made default according to the Principle of least astonishment)
    • Enable the all options starting with “Save” in digikam Configuration > Metadata. This would save all tags, ratings, captions and copyright information directly in the image instead of relying on digikam database for it.
    • Add author and copyright information in digikam Configuration > Identity. I put the following there:


    These steps will ensure that from now on all you files get properly tagged, the way you mean them to be.

What about the images I have already tagged, captioned and rated?

After these setting are applied, digikam enforces them only for images you write to from now onwards. For images that are already in your library, we need a write operation on them to embed the metadata into the files.

This can can be done by creating a custom search that matches all possible ratings one by one, and right clicking and assigning the same rating again. Do the same for all tags too. And now all your metadata should get embedded in the file. Voila!


CrAzY SVN / HTTPD Errors!!! (301, 302 …..)



Sorry, SVN and HTTPD team up to drive people crazy.

I just came across two (or maybe three) of their misdoing in my effort to setup SVN on

1) First, with this in /etc/httpd/conf.d directory :

<VirtualHost *:80>
    DocumentRoot            "/var/www/html"

I got an error

RA layer request failed
svn: PROPFIND request failed on '/pragyan'
svn: PROPFIND of '/pragyan': 302 Found (

I found this article :

It said that the error occurs when some cms meddles with the way non existent file message (404) is shown. This,… was my case. (Thanks to my Praygan CMS). So then I changed my document root to /var/www/svn.

Then with

<VirtualHost *:80>
DocumentRoot            "/var/www/svn"

I got an error

RA layer request failed
svn: PROPFIND request failed on '/pragyan'
svn: PROPFIND of '/pragyan': 301 Moved Permanently (

Article that helped me in this grave time of need was :

It said that the error occurs because, when configuring SVN to work with httpd, the virtualhost document root shouldn’t contain the repository location (or httpd gets confused or something). My repos location was /var/www/svn/pragyan (which was within Document root). I simply changed the DocumentRoot to /var/www/svn/DocumentRoot and all started working well again.