Bug 461785 - "Error 13: Invalid or unsupported executable format" attempt to boot 108.el5xen.x86_64 kernel
Summary: "Error 13: Invalid or unsupported executable format" attempt to boot 108.el5x...
Keywords:
Status: CLOSED DUPLICATE of bug 461658
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen
Version: 5.3
Hardware: All
OS: Linux
medium
urgent
Target Milestone: rc
: ---
Assignee: Xen Maintainance List
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-10 15:38 UTC by Jay Turner
Modified: 2015-01-08 00:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-10 20:27:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jay Turner 2008-09-10 15:38:57 UTC 
Description of problem:
Basically just a placeholder at this point, but all of the machines in the RTT lab (KATE machines) are timing out because of the above error.  The failures actually go back quite some time (to the 20080904.nightly tree at least.)

Will fill in some more details as I get them.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jay Turner 2008-09-10 15:44:59 UTC 
As a note, I brought the machine up in rescue mode and was able to recreate the initrd on the system successfully.  However the machine still fails to boot even with the "new" initrd.  Seeing as this appears to go back many builds, I don't think the kernel is at fault, but no telling.
Comment 2 Denise Dumas 2008-09-10 15:52:06 UTC 
This is probably a dup of Brock's 461536 which Peter is alread working on
Comment 3 Jay Turner 2008-09-10 17:31:45 UTC 
I'm suspicious of throwing this in the dup category. In my case the kernel installed successfully and the initrd was created and looks sane.  The install completes successfully.  It's not until the reboot that things go south.
Comment 4 Brock Organ 2008-09-10 19:10:21 UTC 
what appears to be happening is that the 

kernel-xen-2.6.18-108.el5xen

kernel is getting installed by anaconda in the 0910.nightly tree.  This seems a recent change as a previously installed 0905.nightly image on the same system installs the non-xen kernel (-92.1.10.el5) for a default installation (no installation number).

And it looks like the

kernel-xen-2.6.18-108.el5xen

will not boot when installed as a new package manually on a previous installation.

So I have two questions that I don't know the answer to:

1) why is the kernel-xen-2.6.18-108.el5xen being installed by anaconda in the 0910.nightly tree, instead of kernel-xen-2.6.18-108.el5

2) why is the kernel-xen-2.6.18-108.el5xen displaying the "error 13" error message above?
Comment 5 Jay Turner 2008-09-10 20:04:37 UTC 
So let's make this a kernel bug.  I ran another install of the 20080910.nightly install, but before rebooting, forced installation of the kernel-2.6.18-110.el5.x86_64 kernel.  On reboot the -xen kernel met with the fate described above while the standard kernel booted.  Something is definitely amiss with the -xen kernel.
Comment 6 Chris Lalancette 2008-09-10 20:27:19 UTC 
Yes, this is another instance of the "/proc/xen" screwing up the kernel-xen installation.  Closing this as a dup of 461658.

Chris Lalancette

*** This bug has been marked as a duplicate of bug 461658 ***
Note You need to log in before you can comment on or make changes to this bug.