Bug 523197 - Error creating domain: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\\n')
Summary: Error creating domain: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF im...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 500798
TreeView+ depends on / blocked
 
Reported: 2009-09-14 13:12 UTC by Jan Hutař
Modified: 2011-07-27 17:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-27 17:35:59 UTC


Attachments (Terms of Use)
# LIBVIRT_DEBUG=LEVEL virsh start rhel-i386-client-5-u4-XenPVGuest (5.93 KB, text/plain)
2009-09-14 13:13 UTC, Jan Hutař
no flags Details

Description Jan Hutař 2009-09-14 13:12:12 UTC
Description of problem:
I have installed rhel-i386-client-5-u4-XenPVGuest on the rhel-i386-server-5-u4 host using the Satellite virtual guest provisioning ability and I have ended with guest system which can not boot.


Version-Release number of selected component (if applicable):
redhat-release-5Server-5.4.0.3
libvirt-0.6.3-20.1.el5_4
xen-3.0.3-94.el5


How reproducible:
2 of 2 attempts


Steps to Reproduce:
1. install i386 PV guest from Satellite
2. try to boot it (does not matter if using Satellite WebUI or CLI on the Host)


Actual results:
# virsh start rhel-i386-client-5-u4-XenPVGuest
error: Failed to start domain rhel-i386-client-5-u4-XenPVGuest
error: POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\\n')")


Expected results:
should start


Additional info:
# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     1507     4 r-----    545.3
# xm create rhel-i386-client-5-u4-XenPVGuest
Using config file "/etc/xen/rhel-i386-client-5-u4-XenPVGuest".
Error: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\n')
# uname -a
Linux dhcp-lab-133.englab.brq.redhat.com 2.6.18-164.el5xen #1 SMP Tue Aug 18 16:06:30 EDT 2009 i686 i686 i386 GNU/Linux

Comment 1 Jan Hutař 2009-09-14 13:13:35 UTC
Created attachment 360942 [details]
# LIBVIRT_DEBUG=LEVEL virsh start rhel-i386-client-5-u4-XenPVGuest

Comment 3 Petr Sklenar ⛄ 2009-09-14 14:56:41 UTC
my xen host is rhel54 x86_64 and guest was rhel54i386client paravirt:

redhat-release-5Server-5.4.0.3
libvirt-0.6.3-20.el5
libvirt-0.6.3-20.el5
xen-3.0.3-94.el5
kernel-2.6.18-164.el5
kernel-xen-2.6.18-164.el5

and it works:
# xm create psklenar-xenpvGuest-i386-5Client
Using config file "/etc/xen/psklenar-xenpvguest-i386-5Client".
Started domain psklenar-xenpvguest-i386-5Client

######> then I stopped that guest and:
# virsh start psklenar-xenpvguest-i386-5Client
Domain psklenar-xenpvguest-i386-5Client started

all works as expected, but host was rhel54 x86_64

Comment 4 Petr Sklenar ⛄ 2009-09-14 15:48:19 UTC
I tried more machines and there is some issue with machine installed with package set = @Everything
virt-manager:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 498, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup
    self.vm.create()
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 287, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\\n')")

I installed 4 machine: three machine (@everything) don't work and one with @base works (Comment #3)

Comment 5 Justin Sherrill 2009-09-15 15:55:28 UTC
Ok, so i figured this out.

When you do an @Everything install it installs multiple (non-Xen) kernels.

I mounted the disk image and found the following kernel packages installed:

kernel-xen-2.6.18-164.el5
kernel-2.6.18-164.el5
kernel-PAE-2.6.18-164.el5


and grub was set to boot the PAE kernel which won't work for Xen PV!

So essentially you can't ever use @Everything with a Xen PV install, unless you can do something like:

@Everything
-kernel-PAE
-kernel

I'd have to test that though, much safer to do @Base.

I edited the disk image and changed grub to boot to the kernel-xen kernel, and it boots up fine on dhcp-lab-133.englab.brq.redhat.com

-Justin

Comment 6 Jiri Denemark 2009-09-15 18:15:58 UTC
So it turns out it's not a Xen bug. It might be a bug in another component but I'm not sure which one. That said, I'm closing this as NOTABUG. If you feel there is something to be fixed in another component, feel free to reopen it and set the component appropriately. Or even file a completely new bug with more appropriate description.

Comment 7 Petr Sklenar ⛄ 2009-09-16 10:37:03 UTC
Hello,
I created ks i386-rhel54Client-paravirt-guest with following package set: 

@Everything
-kernel-PAE
-kernel

which works for me and right kernel-xen is booted

Comment 8 Brandon Perkins 2009-09-17 02:51:51 UTC
This is definitely not a kickstart tree issue, I also confirmed its the identical behavior on RHEL 5.3.  A simpler way to create this scenario is to do:

%packages --resolvedeps

kernel
kernel-PAE
kernel-debug
@ Base


in the kickstart file (so you don't have to wait for @ Everything.  So, even though we have cleared the 5.4 kickstart trees from being a problem, it does feel like this is either a Kernel or Anaconda bug.  I don't know if there is any way to create a proper conflicts for the paravirtualized guest case, so it might just be a situation where Anaconda shouldn't allow this to occur.  I'll leave it to the discretion of others, but I feel this is a valid bug to reopen and assign to kernel or anaconda.

Comment 9 Chris Lalancette 2009-09-17 07:47:58 UTC
(In reply to comment #8)
> This is definitely not a kickstart tree issue, I also confirmed its the
> identical behavior on RHEL 5.3.  A simpler way to create this scenario is to
> do:
> 
> %packages --resolvedeps
> 
> kernel
> kernel-PAE
> kernel-debug
> @ Base
> 
> 
> in the kickstart file (so you don't have to wait for @ Everything.  So, even
> though we have cleared the 5.4 kickstart trees from being a problem, it does
> feel like this is either a Kernel or Anaconda bug.  I don't know if there is
> any way to create a proper conflicts for the paravirtualized guest case, so it
> might just be a situation where Anaconda shouldn't allow this to occur.  I'll
> leave it to the discretion of others, but I feel this is a valid bug to reopen
> and assign to kernel or anaconda.  

It's definitely not a kernel bug.  You don't want to have kernel-PAE conflict with kernel-xen, for instance; you might want to do something funky where you are dual-booting the same domain both as an HVM guest and a PV guest.  And in the above scenario, you are deliberately shooting yourself in the foot.

So that just leaves the "Everything" install, which is the only real source of problem.  In that case, anaconda should still be choosing the kernel-xen as the default kernel, since it is a PV guest.  Therefore, the only reasonable place to ask for a bugfix would be anaconda.

Chris Lalancette

Comment 10 Jan Hutař 2009-09-21 11:23:59 UTC
Please see comments #8 and #9 to see why I'm re-opening this.

Comment 11 Chris Lumens 2009-09-21 14:20:07 UTC
You chose to do an everything install, which simply does just what its name says - installs everything.  That's all the packages, even though they may not make any sense.  If you want finer grained control over your installed package set, you can deselect things in the UI, remove them via kickstart as you have done, or simply not do an Everything install.

Problems like this are why we have stopped recommending these sorts of installs, and I do not want to add an ever-increasing and ever-out-of-date list of hacks to anaconda for what packages shouldn't be part of Everything and why.

Comment 12 Chris Lalancette 2009-09-21 14:39:13 UTC
(In reply to comment #11)
> You chose to do an everything install, which simply does just what its name
> says - installs everything.  That's all the packages, even though they may not
> make any sense.  If you want finer grained control over your installed package
> set, you can deselect things in the UI, remove them via kickstart as you have
> done, or simply not do an Everything install.
> 
> Problems like this are why we have stopped recommending these sorts of
> installs, and I do not want to add an ever-increasing and ever-out-of-date list
> of hacks to anaconda for what packages shouldn't be part of Everything and why.  

But that's not what this is about.  Selecting "Everything", and having anaconda install everything under the sun is just fine.  The problem is that anaconda chose the wrong kernel as the default kernel at the end of the install.  Anaconda knows that it is running as a Xen guest, and in the normal circumstance, it does the right thing and installs the kernel-xen package and sets it as the default.  For some reason in the Everything install, it installs the kernel-xen package, but does not set it as default, which is the problem.

Chris Lalancette

P.S.  I have not verified the problem myself, but this is going off of the problem described in Comment #8 and #9.

Comment 13 Jan Hutař 2009-09-22 06:11:43 UTC
Yep, exactly. Which component is choosing correct default kernel?


Note You need to log in before you can comment on or make changes to this bug.