Loopback mountin’…a specific partition in a disk image file

Loopback mounts are cool as heck. You can take a file containing an image of a partition and mount on top of your regular filesystem. But what if you have a file containing an entire disk image rather than just an image of a single partition? It’s common to deal with such files when dealing with User Mode Linux (UML) root filesystems.

Well, you can still do it. It turns out that losetup and hence mount which uses losetup to do loopback mounting, allow you to specify an offset option to specify the starting offset into the file from which to read. Now the only trick is to use fdisk to figure out where the partitions are:

$ fdisk -l -u -C 592 FedoraCore6-x86-root_fs 

Disk FedoraCore6-x86-root_fs: 0 MB, 0 bytes
255 heads, 63 sectors/track, 592 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes

                  Device Boot      Start         End      Blocks   Id  System
FedoraCore6-x86-root_fs1   *          63      208844      104391   83  Linux
FedoraCore6-x86-root_fs2          208845     6281414     3036285   8e  Linux LVM

$ echo $((63 * 512))
32256
$ sudo mount FedoraCore6-x86-root_fs fc6-loop -o loop,offset=32256

In this case, I was wanting to mount the first partition, which according to fdisk, starts at sector 63. In order to convert that to a byte offset, I simply multiplied 63 by 512 (the number of bytes per sector) to get a byte offset of 32256. Note that the second partition can’t be mounted this way, because it’s an LVM partition.

Adding a -p option to touch

I’ve sometimes wished that the UNIX touch command had the same -p option as mkdir. With a little bit of scripting, it can:

#!/bin/sh

mkdir="/bin/mkdir"
touch="/usr/bin/touch"

for arg in $*; do
    if [ "$arg" = "-p" ]; then
        opt_p=true
        continue
    fi
    if [ "$opt_p" = "true" ]; then
        $mkdir -p $(dirname $arg) && $touch $arg
    else
        $touch $arg
    fi
done

Non-functioning Alt key in qemu-0.8.2 displayed to X11.app

The Alt key on my US English keyboard going to OS X X11.app going to qemu-0.8.2 (using my own qemu-0.8.2 RHEL 4 package) on my RHEL 4 Linux box is not happening. Instead, this is spewed to the console.

Warning: no scancode found for keysym 310

Strange, since xev sees the keypress just fine:

KeyPress event, serial 24, synthetic NO, window 0x1000001,
    root 0x57, subw 0x0, time 411185488, (11,-16), root:(31,48),
    state 0x0, keycode 66 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

I don’t know why the keysym reported by qemu doesn’t match the keysym reported by xev. I’m guessing that it has something to do with the fact that qemu uses SDL, which probably has its own keymap routines, that are apart from the X11 routines.

Technorati tags: linux, qemu, virtualization, rhel

links for 2006-12-17

Technorati tags: linux, rpm, redhat, usermodelinux