Bug 71086 - Boot disks and remote loopback mounted images present a kernel version mismatch (2.4.18-3BOOT vs 2.4.7-10BOOT)
Summary: Boot disks and remote loopback mounted images present a kernel version mismat...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-08 16:55 UTC by Need Real Name
Modified: 2007-04-18 16:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-14 19:41:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Need Real Name 2002-08-08 16:55:44 UTC
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
(ftp.rediris.es),
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
2. 
3. 

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 20:19:31 UTC
Could you give me the URL to the update image you are using?

Comment 2 Need Real Name 2002-08-14 15:26:30 UTC
If you are refering to the update.img, that is the one related to the RedHat
advisory
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
downloaded
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
friday.


Comment 3 Michael Fulbright 2002-08-14 19:41:35 UTC
Jeremy please investigate.

Comment 4 Jeremy Katz 2002-08-14 21:59:32 UTC
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.