Bug 71086 - Boot disks and remote loopback mounted images present a kernel version mismatch (2.4.18-3BOOT vs 2.4.7-10BOOT)
Boot disks and remote loopback mounted images present a kernel version mismat...
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-08-08 12:55 EDT by Need Real Name
Modified: 2007-04-18 12:45 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-14 15:41:39 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 Need Real Name 2002-08-08 12:55:44 EDT
Description of Problem:

(It is not an anaconda one, but it was the component that, in my opinion, is
closer to it)

Installing RH7.2 on a Proliant 380 with a Smart 5i controller failed due to
problems in the
module insertion (cciss.o), which is not found (in a kickstart nfs install).
After many trials and attemps, I accidentally discovered that the kernel present
at the
installation floppies (bootnet.img 2.4.18-3BOOT) is not the same version than
the one
at the loopbackmounted images (stage2.img 2.4.7-10BOOT). This made no modules
available in the second stage, and thus no recognition of the disks.

The same problem exist using the update-disk-20020117.img

The RedHat/ tree and the bootnet image are taken from our local mirror
wich is nightly updated against sunsite.cnlab-switch.ch.

The update image was taken directly from redhat.com

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

How Reproducible:

The error arise in a nfs kickstart installation, but due to its nature, it
should appear on
any (remote?) installation using a boot image from a non-CD media.

Steps to Reproduce:
1.  Just try to install rh72 (with some sligthly non-standard
harware=modularized one) using
a network method

Actual Results:

Expected Results:

Additional Information:
I've been able to solve the problem in two ways. One is to put the correct
cciss.o file onto
the bootnet.img, within the correct place on initrd.img.

The other one was to replace the modules.cgz on the stage2.img.

Both had worked, although I'm not sure if in the first case I also had the
correct modules at
the stage2 image (too many hours crashing the wall).
Comment 1 Michael Fulbright 2002-08-12 16:19:31 EDT
Could you give me the URL to the update image you are using?
Comment 2 Need Real Name 2002-08-14 11:26:30 EDT
If you are refering to the update.img, that is the one related to the RedHat
RHBA-2002:016-06, which I reach from a webpage from Compaq (one related to RH72
drivers for Smart Array 5300 series). The update.img was a prerequisite, and I
it from ftp://updates.redhat.com/7.2/en/os/images/i386/updates-disk-200201 ...
(the other part
is out of the printed compaq webpage.

If you're asking for the stage2.img at server, I cann'ot give you an URL until
Comment 3 Michael Fulbright 2002-08-14 15:41:35 EDT
Jeremy please investigate.
Comment 4 Jeremy Katz 2002-08-14 17:59:32 EDT
In Red Hat Linux 7.3 and later, we verify that the images for the different
stages match to prevent this problem (assuming the file we look for exists). 
The bootnet you're using is from Red Hat Linux 7.3 and so won't work with the
7.2 installer

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