Hello My comments inline <sandeep> -----Original Message----- From: anaconda-devel-list-bounces@xxxxxxxxxx [mailto:anaconda-devel-list-bounces@xxxxxxxxxx] On Behalf Of Ragnar Kjørstad Sent: Wednesday, March 19, 2008 2:58 AM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media On Mon, Mar 17, 2008 at 01:39:29PM +0530, Sandeep_K_Shandilya@xxxxxxxx wrote: > Hello All > > I have moved this discussion from bugzilla to the mailing list > Currently customers have to use driver disks or usb-storage to install > to newer hardware (NICS and disk controllers) for which the OS does > not have support. > The customer has to manually prepare driver disks or give boot time > command line options to locate these driver disk images. > This method could be improved. Yes. > 2) Automatic mounting of partitions with no way to opt-out can lead to > problems over time <sandeep> Do you have any specific areas in the > anaconda loader that you are referrring to? > we will anyway unmount the partition after copying the driver updates > to ramfs. What will happen if I try to install a system that has an existing corrupt vfat filesystem on a removable USB storage device? Or install a system that has a big USB storage device with a very large number of small files? (Appears this code will put the whole filelist in memory?) <sandeep> Firstly the file system on the usb storage partition will be prepared on the fly and there is very little scope for it to get corrupted. Second, We first check that the "oemdrv" dir exists and copy only that directory to the ramdisk. If you have a cross linked vfat file system (Eg. a directory entry pointing to itself) then this code is broken, so is the current driver update code, maybe use glob instead of the current way of doing this, the file names of driver update images need to be strictly *.img then. > 4) What's better about doing this automatically as opposed to actually > having the user specify that "yes, I have a driver disk" > <Sandeep> Think about it this way, Suppose the drivers with new > hardware support are placed in a utility partition (OEM will prepare > this on the > system) on an embedded USB storage device, or thinking a little bit > more into the future the driver may reside on the internet Dell is > already pursuing this and Dell servers to be released in future may > have embedded usb-storage with drivers, diagnostics etc... There appears to be no system to recognize what drivers are actually appropriate for this installation. E.g. it will not work well if there are different drivers needed for different distributions. or for 32bit vs 64bit. <sandeep> The Redhat driver disk format already supports a multi-architecture environment since RHEL 3. The images that are located on the usb-storage media could be multi-arch. the current code will select and load the correct kernel modules. Then coming to the driver rpms, the driver rpms are all dkms, dkms supports multi-arch drivers. Or we must use multi-arch driver rpms in case of binary ones. -- Ragnar Kjørstad Software Engineer Platform Computing _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
