Bug 117596 - PXE kickstart with driver disk
PXE kickstart with driver disk
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-05 13:00 EST by Robert de Rooy
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-21 14:48:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert de Rooy 2004-03-05 13:00:57 EST
Description of problem:

I am looking for a way to use a driver disk in combination with
unattended PXE boot kickstart installs.

Basically there are 2 different types of driver disks we need to worry
about. NIC driver disks and SCSI driver disks.
The problem that we run into is that a version of Red Hat (and this is
not specific to RH EL 3, it applies to all Red Hat and Fedora
versions) is that often the standard version does not have a current
enough driver, or is missing a driver for a specific NIC or SCSI
adapter. This is where we have the option of using driver disks for
regular installs, but this fails when doing network installs with PXE
boot.

Right now what we do in the case of NIC drivers is the following:
- loopback mount images/pxeboot/initrd.img
- unpack modules.cgz
- put new/updated NIC driver in for the BOOT kernel
- rebuild modules.cgz
- patch pcitable and module-info as needed
- umount images/pxeboot/initrd.img

For SCSI (or IDE-RAID, which acts like SCSI):
- loopback mount RedHat/base/stage2.img
- unpack modules.cgz
- put new/updated SCSI driver in for the BOOT kernel
- rebuild modules.cgz
- patch modinfo, modules.dep and pcitable as needed
- umount base2.img

Obviously we then also have to somehow install the regular
uni/smp/bigmem/enterprise/summit versions of the drivers, as otherwise
the machine would either panic on boot because it cannot mount the
root filesystem, or boot without networking.
So what we do is one of the following:
- have the regular drivers copied over during %POST from somewhere
- patch RedHat/base/comps.xml with a driver RPM, put the driver RPM in
RedHat/RPMS and run genhdlist to regenerate hdlist and hdlist2.

In the case of a SCSI driver disk, I see a simple solution. Allow a
new directive in the kickstart file 'driverdisk' with as a parameter a
URL.

The NIC case is more difficult since that driver needs to be
downloaded much earlier then the SCSI driver. In fact it will probably
have to be part of the initrd file in one way or another. Perhaps it
could be possible to simply attach a NIC driver disk to the initrd or
put the whole NIC driver disk inside the initrd file?

In any case, please note that you might actually need 2 driver disks
for a system. One for the NIC and another for the SCSI adapter.
Comment 1 Suzanne Hillman 2004-03-19 12:04:22 EST
Internal RFE bug #118732 entered; will be considered for future releases.
Comment 2 Robert de Rooy 2004-04-22 09:15:37 EDT
Any comment as to why this was closed as WONTFIX?

This is really a problem with a lot of customers trying to push out
automated builds.

And unless we see some kind of fix for this we have no choice, and
will have to continue to hack the install process in the way described
above.

The main problem with the hack process as described above is that it
is too difficult to perform for a lot of people, and some people
dislike modifying the install process in such a way for fear of
loosing support from RH.

The HW vendors will always have new hardware comming out that is not
yet supported with the latest RH release, and we cannot tell people to
wait for x months for a quarterly update release which might fix it.

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