[SLL] The Best of Both Worlds issue with DMRAID

Brett Serkez bserkez at gmail.com
Thu Mar 6 06:07:58 PST 2008


Implementing the environment described in the February issue of LJ on
page 84 "The Best of Both Worlds", ran into two issues.

The first is just odd, on page 85 is shows this syntax for starting
qemu in Windows:

qemu.exe -L . -m 128 -hda \\.\PhysicalDrive0 -soundhw all -localtime

This syntax did not work, with complaints about not being about to
open .\PhysicalDrive0.  The documentation says that the syntax
\\.\PhysicalDrive0 and //./PhysicalDrive0 are the same, but I found
that under WindowsXP SP2, only the later syntax worked.

The second is a show stopped, unless someone can provide some insight.

I have CentOS 5.1 installed and when booted directly, typing df shows
the raw device mounted as follows:

/dev/mapper/via_cbbgcfgaagp2
                       8123200   2865796   4838108  38% /

When booting CentOS via qemu under WindowsXP, eventually fschk fails
complaining it cannot find any files systems labeled /, as this is
what the fstab entry looks like:

LABEL=/                         /       ext3    defaults        1 1

Dropping into a diagnostic, single user shell, I can see that
/dev/mapper is essentially empty, I can access each hard drive using
fdisk on the raw partitions /dev/hda and /dev/hdb and they look like
I'd expect them to.   The errors referenced
/dev/mapper/via_cbbgcfgaagp.

I've tried many creative ways of working around this, to no avail.  I
can see there is a basic conflict between Windows trying to manage the
RAID and Linux.  I tried building a version of initrd that didn't run
dmraid, which did boot without loading dmraid modules, but still with
the same result, still with references to /dev/mapper/via_cbbgcfgaagp
and not being able to locate file systems labeled /.  I'm not sure
why, without dmraid loading, how/why it keeps referencing back to
/dev/mapper/via_cbbgcfgaagp.

Wanted to share my experience with the community and see if perhaps
anyone had an ideas as how to address this issue.

Thank you,

Brett


More information about the linux-list mailing list