On Fri, Mar 11, 2011 at 7:35 AM, Hitesh Khandelwal
<hitesh.iitk@xxxxxxxxx> wrote:
> Replied inline:
> On Wed, Mar 9, 2011 at 9:33 PM, Fajar A. Nugraha <list@xxxxxxxxx> wrote:
>>
>> On Thu, Mar 10, 2011 at 7:34 AM, Hitesh Khandelwal
>> <hitesh.iitk@xxxxxxxxx> wrote:
>> > root = '/dev/sda2 ro'
>>
>> For starters, change that to /dev/xvda2
>>
>> > disk = [
>> >
>> > 'file:/home/hkhande/xen-image/domains/cloud-vm06/disk.img,sda2,w',
>>
>> ... and here as well. Though newer kernel version will silently change
>> sd* to xvd*, sometimes the mapping seems inconsistent (sda -> xvde)
>
>
> As I already mentioned in my earlier post, I tried xvda as well. This is the
> error I received:
> Loading, please wait...
You DO know that those limited error message is almost useless, right?
You need to remove "quiet" and "rhgb" (if present in kernel agrs) and
add "console=hvc0" (if you also have vfb enabled) to get informative
boot message on domU's xen console. Logs like these one are
particularly useful
[ 0.181537] XENBUS: Device with no driver: device/vbd/51712
[ 0.181543] XENBUS: Device with no driver: device/vif/0
[ 0.181548] XENBUS: Device with no driver: device/console/0
... which shows that domU detects some devices
[ 0.388665] blkfront device/vbd/51712 num-ring-pages 1 nr_ents 32.
[ 0.401714] blkfront: sda: barriers enabled
[ 0.402322] sda: sda1 sda2
... which shows that the disk was mapped as xvda (vbd/51712), but the
kernel use "sda" as device name
or
[ 0.175140] XENBUS: Device with no driver: device/vbd/51712
[ 0.811357] blkfront: xvda: barriers enabled
[ 0.812448] xvda: xvda1 xvda2 xvda3
... which shows that the disk was mapped as xvda (vbd/51712), and the
kernel use "xvda" as device name
It's useful because (for instance) in Ubuntu Maverick's
linux-image-2.6.35-25-generic detects the disk sda (even though I use
xvda in domU config file), while Lucid's linux-image-2.6.32-29-virtual
detects it as xvda.
... or you could just use "root=UUID=...." or "root=LABEL=..." and
don't care about sda/xvda mappings.
Also, I think it's better to use "extra" instead of "root" on Xen
config file, so you can just copy the kernel command line from
grub/grub2's menu.lst/grub.cfg. Depending on what you currently have
on grub.cfg, the "extra" line should look like
extra=" root=LABEL=ROOT ro"
or
extra=" root=UUID=9aab45dc-4bcf-426e-947c-c027db28b098 ro"
> mount: mounting none on /dev failed: No such device
> W: devtmpfs not available, falling back to tmpfs for /dev
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
> done.
> Begin: Running /scripts/local-premount ... done.
> [ 5.572796] kjournald starting. Commit interval 5 seconds
> [ 5.572824] EXT3-fs: mounted filesystem with writeback data mode.
> Begin: Running /scripts/local-bottom ... done.
> done.
> Begin: Running /scripts/init-bottom ... done.
> init: ureadahead main process (803) terminated with status 5
This actually look like a complete boot process. You just don't have
the login prompt. Try removing "xencons=hvc" from your "extra" line
(do you even have that in your grub.cfg?).
I use something like this to detect whether hvc0 or ttyS0 is
available, and spawn a login prompt there
#=======================================================
# cat /etc/init/hvc0.conf
# hvc0 - getty
#
# This service maintains a getty on hvc0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
pre-start script
test -c /dev/hvc0 && echo >> /dev/hvc0 || { stop; exit 0; }
end script
respawn
exec /sbin/getty -8 38400 hvc0
#=======================================================
for ttyS0 just create a new file, changing the file name and content
replacing "hvc0" with "tty0". This way whatever console I have (hvc0
when booting PV, ttyS0 when booting HVM) I'll be able to access it.
> I meant, I want to use the same xen kernel I compiled for running Dom0.
> because this
> patch: http://lists.xensource.com/archives/html/xen-devel/2010-10/msg01261.html
> is still absent in ubuntu stock kernels. That patch is part of xen kernel I
> compiled for Dom0, hence want to use the same kernel for DomU as well. Can
> you please elaborate how to use Dom0 kernel and initramfs for booting DomU?
The easiest way? Just install the compiled kernel inside domU. Use
make-kpkg to make your life easier.
>
>>
>> > I also modified /etc/initramfs-tools/modules in Dom0 to include
>> > scsi_mod, sd_mod, blkbk modules, followed by update-initramfs.
>>
>> ... as shown here.
>>
>> blkbk is xen block backend device driver, needed by dom0 but not
>> needed by domU. domU needs xen_blkfront and xen_netfront.
>>
... or do what you already do, but make sure xen_blkfront is also
loaded. Although from your last log it seems the disk is already
detected correctly when you use xvda. You're just missing the login
prompt.
--
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home