[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] bug using bootloader + patch

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Eric Einhorn" <lists@xxxxxxxxxxx>
  • Date: Tue, 13 Mar 2007 08:22:48 -0400 (EDT)
  • Delivery-date: Tue, 13 Mar 2007 05:17:03 -0700
  • Importance: Normal
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi -devel,

I ran into an issue with the pyhton tools when using the bootloader option
in 3.0.4.  4 out of 5 times xen would fail when trying to launch pygrub. 
I tracked the cause down to XendDomainInfo.py's use of all_devices_sxpr()
to find a valid block device.  Devices are stored inside a hash, which,
will come back in an arbitrary order when you iterate it's values.  In my
case, 4 out 5 times it would return my swap vbd first and try to launch
pygrub on it.

Instead, I wanted to use get_vbs() to return the block devices since it
should return a list in the order they were added with device_add() (from
XendConfig.py).  I then found that in _sxp_to_api() the vbd_refs, as well
as vif_refs and vtpm_refs are recreated by itterating over the device
hash.  So it seems all that work device_add did to make a neat order list
was tossed out.

I modified _sxp_to_api to copy the original device _refs lists instead of
iterating to preserve the original order the devices were created.  Also,
as mentioned earlier, I modified _configureBootloader to use get_vbds() so
it will have direct access to the ref list.  I am able to boot with a
bootload everytime now and have had no errors.

Attached is a patch for the changes I made against 3.0.4_1 if anyone is
intersted.  Maybe it'll help someone else.


- Eric

Attachment: xen-device_order.patch
Description: Binary data

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.