On Fri, Jan 14, 2011 at 9:59 AM, GNUbie <gnubie@xxxxxxxxx> wrote:
> When I format the new volume for this new domU, I added that -L /
> option for the sda2 and /boot for the sda1.
Good
> Then, I transferred the files using the dump and restore utilities to
> a mounted directory (e.g. /mnt) where:
>
> /mnt => /dev/sda2
> /mnt/boot => /dev/sda1
How do you know it's actually mapped as sda?
>>>> What does your domU config
>>>> file looks like?
>
> Honestly, I don't know because I don't manage the dom0. But based on
> the documentation, it expects sd* mapping.
You need to get it. Even if it's only to get disk mappings (whatever
format it's in, whether python or xml)
It's possible that the domU config maps the disk as xvdb (for
example). Then all attempts to use xvda2 or sda2 will be useless.
>>>> What does "fdisk -l /path/to/your/disk-image" look like
>
> Right now, the volume is in my other domU's /dev/sdk:
>
> # fdisk -l /dev/sdk
>
> Disk /dev/sdk: 2147 MB, 2147483648 bytes
> 255 heads, 63 sectors/track, 261 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x9f08f669
>
> Device Boot Start End Blocks Id System
> /dev/sdk1 1 17 136521 83 Linux
> /dev/sdk2 18 261 1959930 83 Linux
>
Good,
Try checking to see if the label actually exists. Run
e2label /dev/sdk1
e2label /dev/sdk2
I had cases where I run e2label to setup the label, but it doesn't
show up after reboot. Just to make sure.
> my /etc/fstab for the new domU has been configured like this:
>
> LABEL=/boot /boot ext3 defaults 1 2
> LABEL=/ / ext3 defaults 1 1
> And I also tried changing the first 2 lines with:
>
> /dev/sda1 /boot ext3 defaults 1 2
> /dev/sda2 / ext3 defaults 1 1
At this point you NEED to know what the domU detects the disk as. domU
config file might help.
Also, disable "quiet" on grub config line (if it's there). During boot
of Ubuntu Lucid in my setup, it shows these lines:
[ 0.205765] XENBUS: Device with no driver: device/vbd/51712
[ 0.205782] XENBUS: Device with no driver: device/vif/0
[ 0.205797] XENBUS: Device with no driver: device/console/0
[ 0.205844] Magic number: 1:252:3141
[ 0.205918] /build/buildd/linux-2.6.32/drivers/rtc/hctosys.c:
unable to open rtc device (rtc0)
[ 0.205942] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 0.205957] EDD information not available.
[ 0.206219] Freeing unused kernel memory: 800k freed
[ 0.206757] Write protecting the kernel read-only data: 7800k
Loading, please wait...
[ 0.328049] udev: starting version 151
Begin: Loading essential drivers... ...
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
[ 0.774316] blkfront: xvda: barriers enabled
[ 0.775478] xvda: xvda1 xvda2 xvda3
In particular, you need to look at these lines
[ 0.205765] XENBUS: Device with no driver: device/vbd/51712 =>
"51712" is block device id for xvda
[ 0.774316] blkfront: xvda: barriers enabled
[ 0.775478] xvda: xvda1 xvda2 xvda3 => this shows that
xen_blkfront driver handles the block device xvda, and it correctly
detects three partitions.
Your problem might be something as simple as not having xen block
device frontend installed, either built in or as a module.
--
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home