Bug 472554 - RHEL5.3 Snapshot 3 pxeboot initrd.img file differs from the same file in boot.iso and boot.img on ia64 arch.
Summary: RHEL5.3 Snapshot 3 pxeboot initrd.img file differs from the same file in boot...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: releng
Version: 5.3
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Dennis Gregorovic
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-21 18:08 UTC by Gary Case
Modified: 2008-11-25 04:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-25 04:57:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gary Case 2008-11-21 18:08:10 UTC
Description of problem:
Intel has reported a problem installing RHEL5.3 Snapshot 3 on Itanium using pxeboot (IT 241390). Investigation of the issue found that initrd.img files from the pxeboot directory differ from those found in the boot.iso and boot.img files. As I understand it, the initrd.img files for all install methods should be identical within the same arch.

Version-Release number of selected component (if applicable):
RHEL5.3 Snapshot 3, RHEL5.2 possibly others on ia64 arch.

How reproducible:
Every time

Steps to Reproduce:
1. Compute sha1sum of the initrd.img file from images/boot.img, /images/boot.iso and also the sha1sum of images/pxeboot/initrd.img, 
2. Sums differ.
  
Actual results:

RHEL5.3-Server-20081113.1 install tree
sha1sum comparisons of pxeboot, boot.img, boot.iso and DVD ISO vmlinuz and initrd images

/os/images/pxeboot files
---------------------
[root@dhcp243-139 pxeboot]# sha1sum initrd.img 
bc290dbdf2465f5b94b1b60121a39eac116598e2  initrd.img

[root@dhcp243-139 pxeboot]# sha1sum vmlinuz 
9a2da3d956a96a43b6555ccdabca64598f0c1532  vmlinuz

/os/images/boot.img files
----------------------
[root@dhcp243-139 tmp]# sha1sum initrd.img 
e83ea861e8f15e4d4372d9a28fb6896b2de43c0c  initrd.img

[root@dhcp243-139 tmp]# sha1sum vmlinuz
9a2da3d956a96a43b6555ccdabca64598f0c1532  vmlinuz

/os/images/boot.iso files
----------------------
[root@dhcp243-139 tmp]# sha1sum initrd.img
e83ea861e8f15e4d4372d9a28fb6896b2de43c0c  initrd.img

[root@dhcp243-139 tmp]# sha1sum vmlinuz
9a2da3d956a96a43b6555ccdabca64598f0c1532  vmlinuz

Expected results:

Matching initrd.img files.

Additional info:

Comment 1 Alexander Todorov 2008-11-21 18:11:24 UTC
Adding clumens to CC list.

Chris,
you told me that anaconda executes mk-images once per build per arch and then incorporates the initrd.img into various places in the tree. This is true for other arches but not ia64 as it appears. Is this anaconda bug or the builders are to blame?

Comment 3 Alexander Todorov 2008-11-21 18:16:55 UTC
with snap #4:

934abf5ca70c769e9dabb1cdb39a01ff53ed1d54  boot.img/initrd.img
10589ec26fef1505b16964a11704d22987115b07  pxeboot/initrd.img

Comment 4 Alexander Todorov 2008-11-21 18:28:56 UTC
zcat /mnt/bootiso/initrd.img | cpio -t produces the same file listing for both images.

the content of the modules/modules.cgz file from both images also seems the same.

Comment 5 Chris Lumens 2008-11-21 19:01:00 UTC
Let me see if I understand the problem correctly.

If they try to pxeboot for an NFS install, the install fails because the module for one of their ethernet cards (the e100, I believe) is not present.  However, if they use the other ethernet card (e1000) then the install works.

On the other hand if they use the boot.iso or boot.img, then the install works fine?

Comment 6 Gary Case 2008-11-21 19:03:34 UTC
Chris, 

I believe that's what's occurring here. I was asking if we'd reproduced the issue here when we discovered the hash differences in the files. That's why I went ahead with opening the BZ without having reproduced it on site.  I'm working with the GSS lab manager to get the 5.3 S3 pxe files on our pxe server so I can try installing to our coldfusion3e.

Comment 7 Gary Case 2008-11-21 21:35:54 UTC
I'm dropping the severity to "3" on this issue. I'm unable to reproduce it using my hardware. I've asked Intel for more information to see exactly what it is that they're doing.

Comment 9 Gary Case 2008-11-25 04:57:27 UTC
And we have our answer! My Intel contact mistyped the kernel entry in elilo.conf, so everything's okay after all.


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