This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 21694 - update 6.2 -> 7.0. No inclusion of needed disk driver in new kernel.
update 6.2 -> 7.0. No inclusion of needed disk driver in new kernel.
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2000-12-04 13:11 EST by Need Real Name
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-11 14:07:03 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 2000-12-04 13:11:48 EST
I run 6.2 with the EATA disk controler driver. I perform an update from
CD to RH7.0. The update request to use the diskdriver.img to find eata. 
Everything is fine.

I reboot on the new kernel, it does not work: the new kernel did not
make any provision to have eata included at boot time to drive the
disk controler.
Comment 1 Michael Fulbright 2000-12-04 14:02:51 EST
Passed to QA to reproduce.
Comment 2 Need Real Name 2000-12-08 04:05:07 EST
I upgraded a bunch of computers and reached the following conclusion:

- If lilo.conf before the upgrade, has a label 'linux' which is the
  default boot image, the upgraded kernel will include the correct disk
  driver and everything will be fine.
- however, most of my computers, have 2 kernels: a 'linux', which is
  the base kernel of the install, then a 'bzImage' which is the
  default. In such a case, upgrading such a system will make 'linux'
  the default boot kernel, but this new kernel will not include the
  disk driver. Hopefully I can still boot on my old 'bzImage', recompile
  the source to make a new 'bzImage' incorporating the drivers then reboot.
  (after the 'make mrproper'-smp bug :-))
Comment 3 Need Real Name 2000-12-08 07:55:15 EST
Well things are not so clear: I upgraded two more computers, each one having
just a single 'linux' entry in lilo.conf. The upgrade went allright, I made
rescue disk, but at reboot time, the kernels did not include the required
disk driver! One was eata (again) but the other was AIC7xxx.

To be able to reboot, I wanted to rebuilt the rescue disk again since
the rescue did not contain also the correct disk drivers! (I wanted to
build the rescue disk again since I made some mistake when copying a
kernel made from another computer onto them).

So, to rebuild the rescue disk, I restart completely the update process.
This way the system would allow me to build new rescue disk and this time
I knew what to do to correctly overwrite the kernel on the disk...

First thing, anaconda wants to re-install packages that it just installed
a few minutes ago!

On one computer (fs), the first running of the upgrade processed about
1140 megs(!). The second running, just 118 megs. I made the rescue disk,
recovered the kernel on it with a kernel made from another computer and
was okay to get back control on the computer.

On the second computer (lexis), the first and second running of the upgrade
processed about 1140 megs also. But what is very strange is that, the 2th time,
the installed kernel had the correct disk drivers! (aic7xxx).

So there is at least 2 problemes:

- why a 'just-upgraded' system, if upgraded again, requires a variable
  amount of data to 're-upgrade' a system instead of 0 bytes ?
- why, sometimes, an upgrade will not correctly add required scsi disk
  drivers and sometimes it will ??

BTW: it would be really nice if a booting linux kernel, instead of
panicing when realizing that it has no correct disk driver, ask for
a driver disk...

(all this with CD install since bootnet does not want of eata drivers)
Comment 4 Michael Fulbright 2001-04-11 12:04:56 EDT
Matt do you have any ideas?

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