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?) > 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. -- 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