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.
On Wed, 2012-05-16 at 12:29 +0100, Dmitry Morozhnikov wrote:> 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.Right, this is definitely a bug. Thanks for reporting. The problem is that the libxl bootloader infrastructure is updating the caller provided domain configuration with the result of running the bootloader, but this is only valid for the current guest, not the rebooted version. Which means that when it gets re-used on reboot it all goes wrong. As it happens xen-unstable does not suffer from this because it always reparses the config file (and hence reinitialises the domain configuration) on reboot. However, that''s a bit of a coincidence, and IMHO it is ugly for the libxl to replace information in user supplied datastructures like this. I have just proposed a patch to remove this trap. Unfortunately the possibilities for fixing this in 4.1 are rather limited since it doesn''t provide the same level of infrastructure for doing this.> Solution is simple, remove code to append this parameters:That breaks the ability to use pygrub+kernel to boot a specific kernel from the guest fs. I don''t know if people use this functionality but I''d be reluctant to remove it. Ian.
Ian Campbell
2012-May-17 16:52 UTC
Re: [Xen-users] libxl vs pygrub in 4.1.2 on rebooting domU
On Wed, 2012-05-16 at 12:29 +0100, Dmitry Morozhnikov wrote:> 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.Right, this is definitely a bug. Thanks for reporting. The problem is that the libxl bootloader infrastructure is updating the caller provided domain configuration with the result of running the bootloader, but this is only valid for the current guest, not the rebooted version. Which means that when it gets re-used on reboot it all goes wrong. As it happens xen-unstable does not suffer from this because it always reparses the config file (and hence reinitialises the domain configuration) on reboot. However, that''s a bit of a coincidence, and IMHO it is ugly for the libxl to replace information in user supplied datastructures like this. I have just proposed a patch to remove this trap. Unfortunately the possibilities for fixing this in 4.1 are rather limited since it doesn''t provide the same level of infrastructure for doing this.> Solution is simple, remove code to append this parameters:That breaks the ability to use pygrub+kernel to boot a specific kernel from the guest fs. I don''t know if people use this functionality but I''d be reluctant to remove it. Ian.