Your message dated Thu, 24 Nov 2011 09:48:20 +0000
with message-id <[email protected]>
and subject line Re: [Pkg-xen-devel] Bug#649349: xen-hypervisor-4.1-amd64:
pygrub fails due to invalid opcode trapped
has caused the Debian Bug report #649349,
regarding xen-hypervisor-4.1-amd64: pygrub fails due to invalid opcode trapped
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
649349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649349
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: xen-hypervisor-4.1-amd64
Version: 4.1.1-3
Severity: important
Whenever I try to start a domU, xm create failed for
'Boot loader didn't return any data!'.
% sudo xm create -c squeeze.cfg
Using config file "/etc/xen/squeeze.cfg".
Error: Boot loader didn't return any data!
It seems related to the following error in dmesg
[1440.163935] pygrub[3654] trap invalid opcode ip:7f732a997c50 sp:7fff60eb2258
error:0 in ld-2.13.so[7f732a984000+1f000]
Note that pygrub does NOT fail If I launch 'pygrub mydisk.img' on a standard
kernel boot, only if the hypervisor is used (tested with linux-image-3.0.0
and linux-image-2.39.2)
Here are logs taken from xend.log
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:103)
XendDomainInfo.create(['vm', ['name', 'squeeze'], ['memory', '128'],
['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_crash', 'restart'],
['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['vcpus', '2'],
['oos', 1], ['bootloader', '/usr/lib/xen-default/bin/pygrub'],
['bootloader_args', ''], ['image', ['linux', ['root', '/dev/xvda2 ro'],
['videoram', 4], ['tsc_mode', 0], ['nomigrate', 0]]], ['s3_integrity', 1],
['device', ['vbd', ['uname',
'file:/home/xen/data/xen/domains/squeeze/disk.img'], ['dev', 'xvda2'], ['mode',
'w']]], ['device', ['vbd', ['uname',
'file:/home/xen/data/xen/domains/squeeze/swap.img'], ['dev', 'xvda1'], ['mode',
'w']]], ['device', ['vif', ['ip', '192.168.1.42'], ['mac',
'00:16:3E:3A:04:EB'], ['bridge', 'xenbr0']]]])
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:2498)
XendDomainInfo.constructDomain
[2011-11-20 09:01:11 2779] DEBUG (balloon:187) Balloon: 1687712 KiB free; need
16384; done.
[2011-11-20 09:01:11 2779] DEBUG (XendDomain:476) Adding Domain: 3
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:2836)
XendDomainInfo.initDomain: 3 256
[2011-11-20 09:01:11 3654] DEBUG (XendBootloader:113) Launching bootloader as
['/usr/lib/xen-default/bin/pygrub', '--args=root=/dev/xvda2 ro ',
'--output=/var/run/xend/boot/xenbl.8881',
'/home/starch/data/xen/domains/squeeze/disk.img'].
[2011-11-20 09:01:11 2779] ERROR (XendBootloader:214) Boot loader didn't return
any data!
[2011-11-20 09:01:11 2779] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py", line
474, in start
XendTask.log_progress(31, 60, self._initDomain)
File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line 209, in
log_progress
retval = func(*args, **kwds)
File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py", line
2838, in _initDomain
self._configureBootloader()
File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py", line
3285, in _configureBootloader
bootloader_args, kernel, ramdisk, args)
File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendBootloader.py", line
215, in bootloader
raise VmError, msg
VmError: Boot loader didn't return any data!
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy:
domid=3
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:2406) No device model
[2011-11-20 09:01:11 2779] DEBUG (XendDomainInfo:2408) Releasing devices
[2011-11-20 09:01:11 2779] ERROR (XendDomainInfo:108) Domain construction failed
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
xen-hypervisor-4.1-amd64 depends on no packages.
Versions of packages xen-hypervisor-4.1-amd64 recommends:
ii xen-utils-4.1 4.1.1-3
Versions of packages xen-hypervisor-4.1-amd64 suggests:
pn xen-docs-4.1 <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On Wed, 2011-11-23 at 22:42 +0100, Alexandre Vaissière wrote:
> Le 23/11/2011 15:08, Ian Campbell a écrit :
> >>> If you boot the same kernel natively what happens when you run pygrub?
> >>> (this should work natively, although obviously you won't be able to
> >>> actually start a VM).
> >> Yes it does work: I see the grub interface.
> > What happens if you pass "noxsave" to the native kernel?
> >
> > [...]
> > If I am right then using "noxsave" on native should demonstrate the
> > issue as well and show that there is a bug in libc.
> >
> you are right. With noxsave, I have same behaviour of pygrub under a
> native kernel.
Good. Well not "good" but you know what I mean.
> > However that doesn't rule out a bug in the hypervisor as well since it
> > should support xsave... except I've just noticed that xsave is
> > deliberately disabled in Xen 4.1!
> >
> > It has been re-enabled in xen-unstable with the comment "re-enable xsave
> > by default now that it supports live migration" (so it will work in 4.2
> > when it is released). This suggests that you could try with "xsave=1" on
> > your hypervisor command line (but that migration won't work).
> >
> With xsave=1 pygrub works ! However xend segfaults later while starting
> the domU :/
> Will try to get a stack, but as you state below:
>
> > Which seems to already be reported and fixed upstream:
> > http://sourceware.org/bugzilla/show_bug.cgi?id=13007
> > as well as against glibc in Debian http://bugs.debian.org/646549. The
> > fix is fixed in glibc-package SVN so ought to be fixed with the next
> > upload (2.13-22).
> >
> Maybe I should wait for this libc release before going further.
I think that would be a good idea.
I think this bug can be closed and a new one opened if the xend seg
fault persists after the libc upgrade so I am doing that now.
Ian.
--
Ian Campbell
Novinson's Revolutionary Discovery:
When comes the revolution, things will be different --
not better, just different.
--- End Message ---
