Bug 461785 - "Error 13: Invalid or unsupported executable format" attempt to boot 108.el5xen.x86_64 kernel
"Error 13: Invalid or unsupported executable format" attempt to boot 108.el5x...
Status: CLOSED DUPLICATE of bug 461658
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
All Linux
medium Severity urgent
: rc
: ---
Assigned To: Xen Maintainance List
Martin Jenner
: Regression
Depends On:
  Show dependency treegraph
Reported: 2008-09-10 11:38 EDT by Jay Turner
Modified: 2015-01-07 19:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-10 16:27:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2008-09-10 11:38:57 EDT
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:
Actual results:

Expected results:

Additional info:
Comment 1 Jay Turner 2008-09-10 11:44:59 EDT
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 11:52:06 EDT
This is probably a dup of Brock's 461536 which Peter is alread working on
Comment 3 Jay Turner 2008-09-10 13:31:45 EDT
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 15:10:21 EDT
what appears to be happening is that the 


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


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 16:04:37 EDT
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 16:27:19 EDT
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.