[Xen-users] libxl vs pygrub in 4.1.2 on rebooting domU

[Dmitry Morozhnikov <dmiceman@xxxxxxx>]

Hello, all.

There is a bug in 4.1.2, at least in gentoo. The question is if it 
already fixed or not.
If someone issue reboot command from inside domU using pygrub 
bootloader, then libxl, or more precisely, make_bootloader_args() in 
libxl_bootloader.c will append parameters --kernel, --ramdisk and --args 
on the second start. So, command line for the pygrub will look like:
usr/bin/pygrub --kernel=/var/run/libxl/boot_kernel.KyI4aX 
--ramdisk=/var/run/libxl/boot_ramdisk.th_SXc 
--args=root=UUID=15c4dce6-e5fe-493f-b738-32b8e7ef829e ro console=hvc0 
quiet  --output=/var/run/libxl/bl.nVj8nF/fifo --output-format=simple0 
--output-directory=/var/run/libxl/ /var/xen/vs92.img
But that is completely wrong from the pygrub side! It bail out with:

Traceback (most recent call last):
  File "/usr/bin/pygrub", line 783, in <module>
    data = fs.open_file(chosencfg["kernel"]).read()
IOError: [Errno 2] No such file or directory

Because there is no /var/run/libxl/boot_kernel.KyI4aX in inside of domU 
disk image.
Solution is simple, remove code to append this parameters:

--- libxl_bootloader.c.orig     2011-10-21 02:05:42.000000000 +0900
+++ libxl_bootloader.c  2012-05-16 19:29:45.592158162 +0900
@@ -44,12 +44,14 @@

     flexarray_set(args, nr++, (char *)info->u.pv.bootloader);

+    /*
     if (info->kernel.path)
         flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s", 
info->kernel.path));
     if (info->u.pv.ramdisk.path)
         flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", 
info->u.pv.ramdisk.path));
     if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0')
         flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", 
info->u.pv.cmdline));
+    */

     flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo));
     flexarray_set(args, nr++, "--output-format=simple0");

Or, alternatively, remove handling of this parameters in pygrub.

The idea to reuse this parameters on domU restart looks completely wrong 
for me anyway. What about situation when someone update domU system with 
new kernel and new kernel parameters and issue reboot command on purpose?
P.S. I'll be glad to hear what I'm completely wrong, all is fine with 
xen code, the problem is on my side and developers actually tested 
rebooting of domU before release. Sorry, then.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users