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.
Here are some of the questions Jeremy had with regard to this patch. Please read inline <sandeep> A few comments from a quick look: 1) Instead of posting patches in private bugs, it's far better to send them to anaconda-devel-list so they can actually be looked at and commented on by the community, not just some private Dell/Red Hat interaction, that is what I have done. 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.
3) The naming is terrible. What's OEM specific about this functionality? <Sandeep> Well, nothing OEM about it except the OEM's would like to install the drivers that they have tested and qualified with NEW hardware. 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...
regards, Sandeep
Sandeep_K_Shandilya@Dell.com 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.
Here are some of the questions Jeremy had with regard to this patch. Please read inline <sandeep> A few comments from a quick look:
- Instead of posting patches in private bugs, it's far better to send
them to anaconda-devel-list so they can actually be looked at and commented on by the community, not just some private Dell/Red Hat interaction, that is what I have done. 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.
- The naming is terrible. What's OEM specific about this
functionality? <Sandeep> Well, nothing OEM about it except the OEM's would like to install the drivers that they have tested and qualified with NEW hardware. 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...
I'm a user. It sounds to me like we have a vendor's hear.
No hardware I use has a binary-only driver that I use. If the driver's not open-source, I don't want it.
Sometimes I've found it necessary to use a driver that is open-source (mostly)[1] but is no incorporated into the kernel as shipped by my vendor - Red Hat/Fedora, SUSE/OpenSUSE, Debian, Ubuntu, and it's a pain.
If you're a vendor supporting Linux I appreciate that, and if you do it properly I will tend to favour your products.
[1] I'll name names. The madwifi driver. I'm happy with how well it works, I'm not entirely happy with the Very Crude Hack someone's engineered to help users keep in step, and when I can find wireless that works less painfully than Atheros I will buy it.
I ignore the binary-only drivers from ATI and nvidia. I want to be able to choose when to install my primary vendor's updates, not wait for someone else to catch up. Not even one day.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks bunnies through garden hoses. I'm taking about whether it works at all, not how swish it is, and I'm talking about on-board graphics.
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
Hello
Qualified drivers for server hardware that are on on support.dell.com are dkms rpms (http://linux.dell.com/projects.shtml#dkms). The licensing is GPL.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com on behalf of John Summerfield Sent: Mon 3/17/2008 5:27 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically from usb-storage media
Sandeep_K_Shandilya@Dell.com 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.
Here are some of the questions Jeremy had with regard to this patch. Please read inline <sandeep> A few comments from a quick look:
- Instead of posting patches in private bugs, it's far better to send
them to anaconda-devel-list so they can actually be looked at and commented on by the community, not just some private Dell/Red Hat interaction, that is what I have done. 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.
- The naming is terrible. What's OEM specific about this
functionality? <Sandeep> Well, nothing OEM about it except the OEM's would like to install the drivers that they have tested and qualified with NEW hardware. 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...
I'm a user. It sounds to me like we have a vendor's hear.
No hardware I use has a binary-only driver that I use. If the driver's not open-source, I don't want it.
Sometimes I've found it necessary to use a driver that is open-source (mostly)[1] but is no incorporated into the kernel as shipped by my vendor - Red Hat/Fedora, SUSE/OpenSUSE, Debian, Ubuntu, and it's a pain.
If you're a vendor supporting Linux I appreciate that, and if you do it properly I will tend to favour your products.
[1] I'll name names. The madwifi driver. I'm happy with how well it works, I'm not entirely happy with the Very Crude Hack someone's engineered to help users keep in step, and when I can find wireless that works less painfully than Atheros I will buy it.
I ignore the binary-only drivers from ATI and nvidia. I want to be able to choose when to install my primary vendor's updates, not wait for someone else to catch up. Not even one day.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks bunnies through garden hoses. I'm taking about whether it works at all, not how swish it is, and I'm talking about on-board graphics.
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mar 17, 2008, at 6:21 AM, Sandeep_K_Shandilya@Dell.com <Sandeep_K_Shandilya@Dell.com
wrote:
Hello
Qualified drivers for server hardware that are on on support.dell.com are dkms rpms (http://linux.dell.com/projects.shtml#dkms ). The licensing is GPL.
The licensing of what is GPL? DKMS? I looked at dkms at one point and viewed as something I don't really need. Correct me if I'm wrong, but it's a shim that lets kernel modules be loaded on any version (within reason) of the kernel. You're still distributing binary-only drivers in that case. To me that's a major loss because I, as the user, don't want to go to support.dell.com and hunt for drivers. I just want the OS to provide them and not have to worry about it.
Also, I was unable to find any Linux drivers for server hardware on support.dell.com.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com on behalf of John Summerfield Sent: Mon 3/17/2008 5:27 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically from usb-storage media
Sandeep_K_Shandilya@Dell.com 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.
Here are some of the questions Jeremy had with regard to this patch. Please read inline <sandeep> A few comments from a quick look:
- Instead of posting patches in private bugs, it's far better to
send them to anaconda-devel-list so they can actually be looked at and commented on by the community, not just some private Dell/Red Hat interaction, that is what I have done. 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.
- The naming is terrible. What's OEM specific about this
functionality? <Sandeep> Well, nothing OEM about it except the OEM's would like to install the drivers that they have tested and qualified with NEW hardware. 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...
I'm a user. It sounds to me like we have a vendor's hear.
No hardware I use has a binary-only driver that I use. If the driver's not open-source, I don't want it.
Sometimes I've found it necessary to use a driver that is open-source (mostly)[1] but is no incorporated into the kernel as shipped by my vendor - Red Hat/Fedora, SUSE/OpenSUSE, Debian, Ubuntu, and it's a pain.
If you're a vendor supporting Linux I appreciate that, and if you do it properly I will tend to favour your products.
[1] I'll name names. The madwifi driver. I'm happy with how well it works, I'm not entirely happy with the Very Crude Hack someone's engineered to help users keep in step, and when I can find wireless that works less painfully than Atheros I will buy it.
I ignore the binary-only drivers from ATI and nvidia. I want to be able to choose when to install my primary vendor's updates, not wait for someone else to catch up. Not even one day.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks bunnies through garden hoses. I'm taking about whether it works at all, not how swish it is, and I'm talking about on-board graphics.
I have to agree with John here. As a Linux user, one of the major gains is not having to go to twenty different vendor sites to get tiny little drivers just to make the system work. I hear Windows users having to do this and I think it's a huge time waste.
The only legitimate case I can think of where users would want to provide drivers during installation is in the case where they want to install a very old Linux release on very new hardware (RHEL3 on my quad core quadxeon quadsystem!), which seems to be common with EL customers. That's fine, but I also have to agree with Bill in that scanning all volumes for drivers is not a great idea. Works ok for small servers, but when get much larger systems connected to much larger storage devices, suddenly installation takes forever.
Sandeep_K_Shandilya@Dell.com wrote:
Hello
Qualified drivers for server hardware that are on on support.dell.com are dkms rpms (http://linux.dell.com/projects.shtml#dkms). The licensing is GPL.
regards, sandeep.
If your _drivers_ are GPL-licenced, what is Dell doing to have them incorporated into the kernel?
However, if you're talking about this, then I really do not like it. [root@ns ~]# rpm -q dkms dkms-2.0.17.6-1.el4.rf [root@ns ~]# rpm -qi dkms Name : dkms Relocations: (not relocatable) Version : 2.0.17.6 Vendor: Dag Apt Repository, http://dag.wieers.com/apt/ Release : 1.el4.rf Build Date: Fri 07 Mar 2008 02:28:07 WST Install Date: Thu 13 Mar 2008 20:41:23 WST Build Host: lisse.leuven.wieers.com Group : System Environment/Kernel Source RPM: dkms-2.0.17.6-1.el4.rf.src.rpm Size : 175402 License: GPL Signature : DSA/SHA1, Fri 07 Mar 2008 02:57:27 WST, Key ID a20e52146b8d79e6 Packager : Dag Wieers dag@wieers.com URL : http://linux.dell.com/dkms/ Summary : Dynamic Kernel Module Support Framework Description : DKMS stands for Dynamic Kernel Module Support. It is designed to create a framework where kernel dependant module source can reside so that it is very easy to rebuild modules as you upgrade kernels. This will allow Linux vendors to provide driver drops without having to wait for new kernel releases while also taking out the guesswork for customers attempting to recompile modules for new kernels. [root@ns ~]#
Given the choice between a system using this, and some other system using fully open source drivers, the first vendor had better have a damned good story (or the other be pitiful). That's exactly what bugs me about the madwifi drivers I found at a CentOS site.
dkms sounds a lot like ndiswrapper, and if a wireless card requires that to work, I don't consider it. There are better choices.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks bunnies through garden hoses. I'm taking about whether it works at all, not how swish it is, and I'm talking about on-board graphics.
Hello
John Dell makes sure that the fixes in the new driver get into the kernel, well we TRY to make our suppliers and partners do that(exceptions exist, I dont want to name any here :(), but what about the end customer in the interim? we release dkms drivers on our support site to handle this scenario. The sources of these drivers also ship with the dkms rpms.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Tuesday, March 18, 2008 5:06 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically from usb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello
Qualified drivers for server hardware that are on on support.dell.com
are dkms rpms (http://linux.dell.com/projects.shtml#dkms). The licensing is GPL.
regards, sandeep.
If your _drivers_ are GPL-licenced, what is Dell doing to have them incorporated into the kernel?
However, if you're talking about this, then I really do not like it. [root@ns ~]# rpm -q dkms dkms-2.0.17.6-1.el4.rf [root@ns ~]# rpm -qi dkms Name : dkms Relocations: (not relocatable) Version : 2.0.17.6 Vendor: Dag Apt Repository, http://dag.wieers.com/apt/ Release : 1.el4.rf Build Date: Fri 07 Mar 2008 02:28:07 WST Install Date: Thu 13 Mar 2008 20:41:23 WST Build Host: lisse.leuven.wieers.com Group : System Environment/Kernel Source RPM: dkms-2.0.17.6-1.el4.rf.src.rpm Size : 175402 License: GPL Signature : DSA/SHA1, Fri 07 Mar 2008 02:57:27 WST, Key ID a20e52146b8d79e6 Packager : Dag Wieers dag@wieers.com URL : http://linux.dell.com/dkms/ Summary : Dynamic Kernel Module Support Framework Description : DKMS stands for Dynamic Kernel Module Support. It is designed to create a framework where kernel dependant module source can reside so that it is very easy to rebuild modules as you upgrade kernels. This will allow Linux vendors to provide driver drops without having to wait for new kernel releases while also taking out the guesswork for customers attempting to recompile modules for new kernels. [root@ns ~]#
Given the choice between a system using this, and some other system using fully open source drivers, the first vendor had better have a damned good story (or the other be pitiful). That's exactly what bugs me about the madwifi drivers I found at a CentOS site.
dkms sounds a lot like ndiswrapper, and if a wireless card requires that to work, I don't consider it. There are better choices.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks bunnies through garden hoses. I'm taking about whether it works at all, not how swish it is, and I'm talking about on-board graphics.
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
- 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.
Imagine trying to search 500 SAN partitions for driver updates.
- 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...
Right, but what good does embedded usb-storage with drivers do you for the next OS release a few months later?
Bill
Hello
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com on behalf of Bill Nottingham Sent: Mon 3/17/2008 8:13 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
- 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.
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
- 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...
Right, but what good does embedded usb-storage with drivers do you for the next OS release a few months later? <sandeep> 1. The same is with hardware and firmware which keep upgrading every few months. 2. OEMs like Dell have baselined to, say, version RHEL 5.0 Every time the hardware/firmware changes which calls for a new driver then we will qualify the new driver and release it on our support page. It will be a very exhaustive effort to qualify all new drivers for every update that Redhat releases. 3. The Embedded usb-storage could also contain other applications Eg diagnostics and the user to boot into it to test the hardware on the server. 4. These drivers will be used at install time to recognise new hardware and in the post install phase of anaconda a dkms rpm (http://linux.dell.com/projects.shtml#dkms) of the driver will be installed. The changes to backend.py in the patch.
Bill
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
Well, you only search things marked 'removable'. *Assuming* SANs, etc. don't set that flag you'll be OK, although I'm not certain they are all sane in this regard.
Right, but what good does embedded usb-storage with drivers do you for the next OS release a few months later?
<sandeep> 1. The same is with hardware and firmware which keep upgrading every few months. 2. OEMs like Dell have baselined to, say, version RHEL 5.0 Every time the hardware/firmware changes which calls for a new driver then we will qualify the new driver and release it on our support page. It will be a very exhaustive effort to qualify all new drivers for every update that Redhat releases.
Then get the drivers *IN THOSE UPDATES*. Heck, thats why those updates are done.
Bill
Hello Bill
We search for drivers in usb-storage very early in the install phase (only usb-storage and cdrom and floppy disk drivers are loaded). at this time we don't have any disk controller or NIC drivers loaded so we will not be searching hard disks or luns on a SAN etc..., so we don't have a problem in this regard.
Regards, Sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of Bill Nottingham Sent: Monday, March 17, 2008 10:00 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automaticallyfromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
Well, you only search things marked 'removable'. *Assuming* SANs, etc. don't set that flag you'll be OK, although I'm not certain they are all sane in this regard.
Right, but what good does embedded usb-storage with drivers do you for
the next OS release a few months later?
<sandeep> 1. The same is with hardware and firmware which keep upgrading every
few months.
- OEMs like Dell have baselined to, say, version RHEL 5.0 Every time
the hardware/firmware changes
which calls for a new driver then we will qualify the new driver
and release it on our support
page. It will be a very exhaustive effort to qualify all new
drivers for every update that Redhat releases.
Then get the drivers *IN THOSE UPDATES*. Heck, thats why those updates are done.
Bill
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
We search for drivers in usb-storage very early in the install phase (only usb-storage and cdrom and floppy disk drivers are loaded). at this time we don't have any disk controller or NIC drivers loaded so we will not be searching hard disks or luns on a SAN etc..., so we don't have a problem in this regard.
I don't believe you understand how current (F9+) versions of the installer work. What you describe just doesn't happen.
Bill
Hello Bill
I am looking at anaconda version 11.4.0.67, loadDriverDisks() is called very early before module loading, Am I looking at the correct version? pub/fedora/linux/development/source/SRPMS/
Regards, Sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of Bill Nottingham Sent: Thursday, April 10, 2008 6:18 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load driversautomaticallyfromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
We search for drivers in usb-storage very early in the install phase (only usb-storage and cdrom and floppy disk drivers are loaded). at this time we don't have any disk controller or NIC drivers loaded so we will not be searching hard disks or luns on a SAN etc..., so we don't have a problem in this regard.
I don't believe you understand how current (F9+) versions of the installer work. What you describe just doesn't happen.
Bill
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Sandeep_K_Shandilya@Dell.com wrote:
Hello Bill
I am looking at anaconda version 11.4.0.67, loadDriverDisks() is called very early before module loading, Am I looking at the correct version? pub/fedora/linux/development/source/SRPMS/
<chortle> I just mentioned that very version on another list. It's much newer than what you will find in RHEL5, it's about what will be in Fedora 9. I found it in the boot.iso from Rawhide, built April 9.
<tosses dust in air> Hmm </tosses dust in air> Might be about what appears in RHEL6. When's it due?
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
I am looking at anaconda version 11.4.0.67, loadDriverDisks() is called very early before module loading, Am I looking at the correct version? pub/fedora/linux/development/source/SRPMS/
Yes. That's part of why it's broken. Where it's called today you'll actually have *no* modules loaded at all, so it won't be able to find anything. Except perhaps a floppy.
Once it's fixed, it will be after the normal device load, which uses udev and loads pretty much everything.
Bill
Sandeep_K_Shandilya@Dell.com wrote:
Hello Bill
We search for drivers in usb-storage very early in the install phase (only usb-storage and cdrom and floppy disk drivers are loaded). at this time we don't have any disk controller or NIC drivers loaded so we will not be searching hard disks or luns on a SAN etc..., so we don't have a problem in this regard.
I wish people would reply in context, I am not at all sure I know which of Bills points this relates to.
As a user, _I_ want my drivers to be in the kernels shipped by my vendor.
I don't want (probably old) drivers hidden away in some USB storage some place. I don't really want them on a CD either. I especially don't want to fire up gcc during install to build a version that matches the install kernel!.
The very best place for my drivers is right there in the kernel shipped by my vendor, whether the vendor is Red Hat/the Fedora Project, Novell/SUSE/OpenSUSE, Debian, Canonical/Ubuntu or Calathumpian Linux Enterprises.
If Dell has no commercial secrets to hide, then I'd think the best way to maintain the relevant drivers is to join Linus, Alan Cox and the rest on the official kernel tree. It's what Adaptec did, when I used one of their SCSI adaptors years ago. You changes will be subject to scrutiny by others and so help the quality of any changes you make.
By all means certify your kit for RHEL, SLES, SLED and whatever seems good, but if there are problems that you need to fix, provide the patches directly to the relevant vendor and/or submit them directly to the official kernel.
If you think you can guess which RHEL kernel people might use to install, then you need to follow Fedora for a while and see what tools are evolving there, including for making custom respins. Remastering Fedora's becoming a trivial affair, and it's likely tools used there will be used in future RHEL.
Regards, Sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of Bill Nottingham Sent: Monday, March 17, 2008 10:00 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automaticallyfromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
Well, you only search things marked 'removable'. *Assuming* SANs, etc. don't set that flag you'll be OK, although I'm not certain they are all sane in this regard.
Right, but what good does embedded usb-storage with drivers do you for
the next OS release a few months later?
<sandeep> 1. The same is with hardware and firmware which keep upgrading every
few months.
- OEMs like Dell have baselined to, say, version RHEL 5.0 Every time
the hardware/firmware changes
which calls for a new driver then we will qualify the new driver
and release it on our support
page. It will be a very exhaustive effort to qualify all new
drivers for every update that Redhat releases.
Then get the drivers *IN THOSE UPDATES*. Heck, thats why those updates are done.
Bill
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Sandeep_K_Shandilya@Dell.com wrote:
Hello
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com on behalf of Bill Nottingham Sent: Mon 3/17/2008 8:13 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
- 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.
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
- 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...
Right, but what good does embedded usb-storage with drivers do you for the next OS release a few months later?
<sandeep> 1. The same is with hardware and firmware which keep upgrading every few months. 2. OEMs like Dell have baselined to, say, version RHEL 5.0 Every time the hardware/firmware changes which calls for a new driver then we will qualify the new driver and release it on our support page. It will be a very exhaustive effort to qualify all new drivers for every update that Redhat releases. 3. The Embedded usb-storage could also contain other applications Eg diagnostics and the user to boot into it to test the hardware on the server. 4. These drivers will be used at install time to recognise new hardware and in the post install phase of anaconda a dkms rpm (http://linux.dell.com/projects.shtml#dkms) of the driver will be installed. The changes to backend.py in the patch.
_I_ maintain the computers for a small school; typically our computers are bought at auction, and they're a pretty mixed lot. It seems Dell was doing well a few years ago, so most of the computers we've bought in the past year have been Dell gx240s, gx260s and gx270s.
One thing I really hat is chasing all over the Internet for drivers for the Dells, the Acers, and the HP-Compaqs we have. Oh, and some whitebox systems built on Intel motherboards. Since Dell's listening, I especially don't like it that the drivers are distributed as self-unpacking exes and that their file names do not (so far as I can tell) reflect the contents. My idea of an ideal install is I boot the computer off the LAN, make a few choices and leave it to run.
Linux is better than that, and I will not willingly chase all over the Internet for Linux drivers. If it doesn't work with standard RHEL5 or SLE{S,D}10 or Debian or whatever I'm trying to run, then it does not work at all.
Bill
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside the box loads and installs it. Maybe not for the old hardware that you already are using but for the upcoming servers.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Tuesday, March 18, 2008 5:18 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com on behalf of Bill Nottingham Sent: Mon 3/17/2008 8:13 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
- 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.
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We only search usb-storage devices.
- 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...
Right, but what good does embedded usb-storage with drivers do you for
the next OS release a few months later?
<sandeep> 1. The same is with hardware and firmware which keep upgrading every
few months.
- OEMs like Dell have baselined to, say, version RHEL 5.0 Every time
the hardware/firmware changes
which calls for a new driver then we will qualify the new driver
and release it on our support
page. It will be a very exhaustive effort to qualify all new
drivers for every update that Redhat releases.
- The Embedded usb-storage could also contain other applications Eg
diagnostics and the user to boot into it
to test the hardware on the server. 4. These drivers will be used at install time to recognise new
hardware and in the post install phase of anaconda
a dkms rpm (http://linux.dell.com/projects.shtml#dkms) of the
driver will be installed. The changes to backend.py
in the patch.
_I_ maintain the computers for a small school; typically our computers are bought at auction, and they're a pretty mixed lot. It seems Dell was doing well a few years ago, so most of the computers we've bought in the past year have been Dell gx240s, gx260s and gx270s.
One thing I really hat is chasing all over the Internet for drivers for the Dells, the Acers, and the HP-Compaqs we have. Oh, and some whitebox systems built on Intel motherboards. Since Dell's listening, I especially don't like it that the drivers are distributed as self-unpacking exes and that their file names do not (so far as I can tell) reflect the contents. My idea of an ideal install is I boot the computer off the LAN, make a few choices and leave it to run.
Linux is better than that, and I will not willingly chase all over the Internet for Linux drivers. If it doesn't work with standard RHEL5 or SLE{S,D}10 or Debian or whatever I'm trying to run, then it does not work at all.
Bill
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside the box loads and installs it. Maybe not for the old hardware that you already are using but for the upcoming servers.
So you have binary-only drivers?
My very favourite rescue disk is Knoppix. Sometimes I have the latest on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix is based off Debian. Klaus Knopper, who created Knoppix, might not see value in including DKMS, he has to make some sacrifices to get it all down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I don't have any support. The kernel's tainted and, I've been told, the fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the discussions about non-free bits in the kernel!
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, March 19, 2008 5:24 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
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside
the box loads and installs it. Maybe not for the old hardware that you
already are using but for the upcoming servers.
So you have binary-only drivers? <sandeep> dkms rpms carry source and binaries. The binarie kernel modules could be used at install time to recognise new hardware. Once install completes then you could install the dkms rpms. Here is a layout of the file system, This should make it a lot clear now.
oemdrv/ oemdrv/megaraid_sas_dd.img oemdrv/mptlinux_dd.img oemdrv/abc/ oemdrv/abc/megaraid_sas_dkms.noarch.rpm oemdrv/def/ oemdrv/def/dkms-2.0.17-1.noarch.rpm oemdrv/hij/ oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary kernel modules ). The rpms contain the binaries and the source. The binaries are compiled against the Dell supported RHEL distro. if you have a new rhel distro the source will be installed by dkms in /usr/src/.. you could compile the driver for your distro and use it. infact dkms is also available in the universe section on ubuntu. dkms is supported on many other linux distro's.
My very favourite rescue disk is Knoppix. Sometimes I have the latest on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix is based off Debian. Klaus Knopper, who created Knoppix, might not see value in including DKMS, he has to make some sacrifices to get it all down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I don't have any support. The kernel's tainted and, I've been told, the fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the discussions about non-free bits in the kernel!
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, March 19, 2008 5:24 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
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside
the box loads and installs it. Maybe not for the old hardware that you
already are using but for the upcoming servers.
So you have binary-only drivers?
<sandeep> dkms rpms carry source and binaries. The binarie kernel modules could be used at install time to recognise new hardware. Once install completes then you could install the dkms rpms.
I have dkms installed on one of my servers, it was pulled in when I installed madwifi, along with a heap of other stuff including gcc. I am not enthused at having gcc installed on a server.
Here is a layout of the file system, This should make it a lot clear now.
oemdrv/ oemdrv/megaraid_sas_dd.img oemdrv/mptlinux_dd.img oemdrv/abc/ oemdrv/abc/megaraid_sas_dkms.noarch.rpm oemdrv/def/ oemdrv/def/dkms-2.0.17-1.noarch.rpm oemdrv/hij/ oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary kernel modules ). The rpms contain the binaries and the source. The binaries are compiled against the Dell supported RHEL distro. if you have a new rhel distro the source will be installed by dkms in /usr/src/.. you could compile the driver for your distro and use it. infact dkms is also available in the universe section on ubuntu. dkms is supported on many other linux distro's.
It is not clear to me that you have answered my question. When I use the term "binary-only drivers," I mean drivers for which Dell does not willingly provide source.
Is there any part of the Dell drivers for which a customer cannot get the source under an OSI-approved licence, preferably GPL2 or later?
I might want to run RHEL, I might prefer CentOS or even Fedora, all of with Anaconda supports, or I might even prefer a distro which Anaconda does not support such as Debian, and I may not care whether it's _certified_ on my platform provided that there's a reasonable probability that it will work and that my hardware vendor won't be too harsh if there's a problem.
_I_ do in fact run all the distros I've just mentioned, and more.
If Dell wants to be difficult about the source code to its drivers, and any of other vendors such as Sun, HP and IBM does provide source and help should I have problems with non-certified hardware, the Dell is batting on a very sticky wicket.
My very favourite rescue disk is Knoppix. Sometimes I have the latest on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix is based off Debian. Klaus Knopper, who created Knoppix, might not see value in including DKMS, he has to make some sacrifices to get it all down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I don't have any support. The kernel's tainted and, I've been told, the fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the discussions about non-free bits in the kernel!
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Monday, March 24, 2008 5:09 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, March 19, 2008 5:24 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
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside
the box loads and installs it. Maybe not for the old hardware that you
already are using but for the upcoming servers.
So you have binary-only drivers?
<sandeep> dkms rpms carry source and binaries. The binarie kernel modules could be used at install time to recognise new hardware. Once install completes then you could install the dkms rpms.
I have dkms installed on one of my servers, it was pulled in when I installed madwifi, along with a heap of other stuff including gcc. I am not enthused at having gcc installed on a server.
<sandeep> Dell does not support or package the madwifi driver. we dont promote this hardware on linux.
Here is a layout of the file system, This should make it a lot clear now.
oemdrv/ oemdrv/megaraid_sas_dd.img oemdrv/mptlinux_dd.img oemdrv/abc/ oemdrv/abc/megaraid_sas_dkms.noarch.rpm oemdrv/def/ oemdrv/def/dkms-2.0.17-1.noarch.rpm oemdrv/hij/ oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary kernel modules ). The rpms contain the binaries and the source. The binaries are compiled against the Dell supported RHEL distro. if you have a new rhel distro the source will be installed by dkms in /usr/src/.. you could compile the driver for your distro and use it. infact dkms is also available in the universe section on ubuntu. dkms is supported on many other linux distro's.
It is not clear to me that you have answered my question. When I use the term "binary-only drivers," I mean drivers for which Dell does not willingly provide source.
<sandeep> dkms is a packaging tool and anybody could use it as a vehicle to publish open-source or non-opensource drivers. I am NOT saying that a *dkms.rpm == opensource driver. I think you mistook me on that.
Is there any part of the Dell drivers for which a customer cannot get the source under an OSI-approved licence, preferably GPL2 or later? < sandeep > For Server hardware, drivers are opensource (all drivers ship with source) a few client hardware drivers are non-opensource( Eg 3d acclerated drivers and wireless drivers )
I might want to run RHEL, I might prefer CentOS or even Fedora, all of with Anaconda supports, or I might even prefer a distro which Anaconda does not support such as Debian, and I may not care whether it's _certified_ on my platform provided that there's a reasonable probability that it will work and that my hardware vendor won't be too harsh if there's a problem.
<sandeep> This patch and RFC is specifically for anaconda.
_I_ do in fact run all the distros I've just mentioned, and more.
If Dell wants to be difficult about the source code to its drivers, and any of other vendors such as Sun, HP and IBM does provide source and help should I have problems with non-certified hardware, the Dell is batting on a very sticky wicket.
<sandeep> As I already mentioned, with respect to Server hardware (Poweredge brand) you should have nothing to worry.
My very favourite rescue disk is Knoppix. Sometimes I have the latest on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix
is based off Debian. Klaus Knopper, who created Knoppix, might not see
value in including DKMS, he has to make some sacrifices to get it all down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I don't have any support. The kernel's tainted and, I've been told, the fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the discussions about non-free bits in the kernel!
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Monday, March 24, 2008 5:09 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, March 19, 2008 5:24 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
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside the box loads and installs it. Maybe not for the old hardware that you already are using but for the upcoming servers.
So you have binary-only drivers?
<sandeep> dkms rpms carry source and binaries. The binarie kernel modules could be used at install time to recognise new hardware. Once install completes then you could install the dkms rpms.
I have dkms installed on one of my servers, it was pulled in when I installed madwifi, along with a heap of other stuff including gcc. I am not enthused at having gcc installed on a server.
<sandeep> Dell does not support or package the madwifi driver. we dont promote this hardware on linux.
I don't think your interpretation of what I said is reasonable.
Here is a layout of the file system, This should make it a lot clear now.
oemdrv/ oemdrv/megaraid_sas_dd.img oemdrv/mptlinux_dd.img oemdrv/abc/ oemdrv/abc/megaraid_sas_dkms.noarch.rpm oemdrv/def/ oemdrv/def/dkms-2.0.17-1.noarch.rpm oemdrv/hij/ oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary kernel modules ). The rpms contain the binaries and the source. The binaries are compiled against the Dell supported RHEL distro. if you have a new rhel distro the source will be installed by dkms in /usr/src/.. you could compile the driver for your distro and use it. infact dkms is also available in the universe section on ubuntu. dkms is supported on many other linux distro's.
It is not clear to me that you have answered my question. When I use the term "binary-only drivers," I mean drivers for which Dell does not willingly provide source.
<sandeep> dkms is a packaging tool and anybody could use it as a vehicle to publish open-source or non-opensource drivers. I am NOT saying that a *dkms.rpm == opensource driver. I think you mistook me on that.
I didn't mistake you, I couldn't figure what you meant or whether you were addressing the question.
Is there any part of the Dell drivers for which a customer cannot get the source under an OSI-approved licence, preferably GPL2 or later? < sandeep > For Server hardware, drivers are opensource (all drivers ship with source)
In that case, what prevents their inclusion in the kernel? Achieve that, and there's no need for dkms, every time RH or CentOS or Debian builds a new kernel, the matching driver is built to and there's no need to go fishing them out of some obscure corner of the imbedded USB storage. And providing source to clients becomes a problem for RH, CentOS, Debian etc, and it's a problem they address very well indeed and their clients understand how it's done.
a few client hardware drivers are non-opensource( Eg 3d acclerated drivers and wireless drivers )
Ah yes, the things I needed for my GX-270.
I might want to run RHEL, I might prefer CentOS or even Fedora, all of with Anaconda supports, or I might even prefer a distro which Anaconda does not support such as Debian, and I may not care whether it's _certified_ on my platform provided that there's a reasonable probability that it will work and that my hardware vendor won't be too harsh if there's a problem.
<sandeep> This patch and RFC is specifically for anaconda.
I appreciate that, but the problem applies equally to _all_ distros people might want to use.
Whether someone chooses to use RHEL, CentOS, Fedora, SLES, Debian, Slackware or something else, if the drivers are open source and part of the kernel, they can see it's certified for RHEL with the standard drivers, insta;; whatever on it, and if it breaks, the RH, CentOS, FedoraProject, Novell, Debian or Patrick has a fair chance of fixing it.
And the FreeBSD, NetBSD, OpenBSD and other BSD folk can all port the drivers to their systems too.
_I_ do in fact run all the distros I've just mentioned, and more.
If Dell wants to be difficult about the source code to its drivers, and any of other vendors such as Sun, HP and IBM does provide source and help should I have problems with non-certified hardware, the Dell is batting on a very sticky wicket.
<sandeep> As I already mentioned, with respect to Server hardware (Poweredge brand) you should have nothing to worry.
I am glad to hear that, but it leaves me puzzled as to why the drivers might be stored in a USB storage device, and why DKMS is needed to load them.
Firmware for (eg) wireless on client hardware maybe, it's a whole different debate.
My very favourite rescue disk is Knoppix. Sometimes I have the latest on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix
is based off Debian. Klaus Knopper, who created Knoppix, might not see
value in including DKMS, he has to make some sacrifices to get it all down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I don't have any support. The kernel's tainted and, I've been told, the fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the discussions about non-free bits in the kernel!
Hello
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Tuesday, March 25, 2008 1:48 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Monday, March 24, 2008 5:09 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, March 19, 2008 5:24 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
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
That is what this patch is attempting to do, solve the problem of hunting for drivers on the net. This patch is changing anaconda so that it automagically looks for drivers in USB storage embedded inside the box loads and installs it. Maybe not for the old hardware
that you already are using but for the upcoming servers.
So you have binary-only drivers?
<sandeep> dkms rpms carry source and binaries. The binarie kernel modules could
be used at install time to recognise new hardware. Once install completes then you could install the dkms rpms.
I have dkms installed on one of my servers, it was pulled in when I installed madwifi, along with a heap of other stuff including gcc. I am not enthused at having gcc installed on a server.
<sandeep> Dell does not support or package the madwifi driver. we dont promote this hardware on linux.
I don't think your interpretation of what I said is reasonable.
Here is a layout of the file system, This should make it a lot clear now.
oemdrv/ oemdrv/megaraid_sas_dd.img oemdrv/mptlinux_dd.img oemdrv/abc/ oemdrv/abc/megaraid_sas_dkms.noarch.rpm oemdrv/def/ oemdrv/def/dkms-2.0.17-1.noarch.rpm oemdrv/hij/ oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary kernel modules ). The rpms contain the binaries and the source. The binaries are compiled against the Dell supported RHEL distro. if you have a new rhel distro the source will be installed by dkms in /usr/src/.. you could compile the driver for your distro and use it. infact dkms is also available in the universe section on ubuntu. dkms
is supported on many other linux distro's.
It is not clear to me that you have answered my question. When I use the term "binary-only drivers," I mean drivers for which Dell does not
willingly provide source.
<sandeep> dkms is a packaging tool and anybody could use it as a vehicle to publish open-source or non-opensource drivers. I am NOT saying that a *dkms.rpm == opensource driver. I think you mistook me
on that.
I didn't mistake you, I couldn't figure what you meant or whether you were addressing the question.
Is there any part of the Dell drivers for which a customer cannot get the source under an OSI-approved licence, preferably GPL2 or later? < sandeep > For Server hardware, drivers are opensource (all drivers ship with source)
In that case, what prevents their inclusion in the kernel? Achieve that,
and there's no need for dkms, every time RH or CentOS or Debian builds a
new kernel, the matching driver is built to and there's no need to go fishing them out of some obscure corner of the imbedded USB storage. And
providing source to clients becomes a problem for RH, CentOS, Debian etc, and it's a problem they address very well indeed and their clients understand how it's done.
<sandeep> We already push the updates upstream either directly or through our partners. Some of our customers prefer to qualify an OS say rhel 5.0. Test that setup and leave it that way till thier next refresh cycle. the duration of which may not align with the redhat update cycle.
a few client hardware drivers are non-opensource( Eg 3d acclerated drivers and wireless drivers )
Ah yes, the things I needed for my GX-270.
I might want to run RHEL, I might prefer CentOS or even Fedora, all of with Anaconda supports, or I might even prefer a distro which Anaconda does not support such as Debian, and I may not care whether it's _certified_ on my platform provided that there's a reasonable probability that it will work and that my hardware vendor won't be too harsh if there's a problem.
<sandeep> This patch and RFC is specifically for anaconda.
I appreciate that, but the problem applies equally to _all_ distros people might want to use.
Whether someone chooses to use RHEL, CentOS, Fedora, SLES, Debian, Slackware or something else, if the drivers are open source and part of the kernel, they can see it's certified for RHEL with the standard drivers, insta;; whatever on it, and if it breaks, the RH, CentOS, FedoraProject, Novell, Debian or Patrick has a fair chance of fixing it.
And the FreeBSD, NetBSD, OpenBSD and other BSD folk can all port the drivers to their systems too.
_I_ do in fact run all the distros I've just mentioned, and more.
If Dell wants to be difficult about the source code to its drivers,
and
any of other vendors such as Sun, HP and IBM does provide source and help should I have problems with non-certified hardware, the Dell is batting on a very sticky wicket.
<sandeep> As I already mentioned, with respect to Server hardware (Poweredge brand) you should have nothing to worry.
<sandeep>
I am glad to hear that, but it leaves me puzzled as to why the drivers might be stored in a USB storage device, and why DKMS is needed to load them.
<sandeep> It is for those customers who dont like to update to a newer release every 6 months. Or for those customers who buy new hardware but use an older OS on it. Secondly the purpose of this patch is to automagically pull the kernel modules and drivers from the usb-storage media. These days usb-storage (flash media) is cheap and as such usb-storage media has good driver support, we dont do driver updates for usb-storage devices often? Thirdly dkms is our method of installing these drivers. your could have a source tarball, source rpm or a binary tarball and achieve the same thing, dkms is one of theways of achieving this.
Firmware for (eg) wireless on client hardware maybe, it's a whole different debate.
My very favourite rescue disk is Knoppix. Sometimes I have the latest
on hand, sometimes not. I am less concerned about security updates than I am about my regular distro, so provided the CD to hand boots I'm happy to use it. I use it for Linux and Windows systems alike - i
can't do a lot to _repair_ a broken Windows system, but it can help with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and
Knoppix
is based off Debian. Klaus Knopper, who created Knoppix, might not
see
value in including DKMS, he has to make some sacrifices to get it all
down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE
system and I have a problem, I have a well-defined path to follow to report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I
don't have any support. The kernel's tainted and, I've been told, the
fact of the driver's being loaded means it could have done bad
things.
I recall an incident, many years ago, when RH was bitten by this very
issue, in respect of CDE that RH used to distribute with RHL. RH couldn't fix CDE and its supplier wouldn't or wouldn't do it in the timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the
discussions about non-free bits in the kernel!
<sandeep> This is not about free and non-free stuff, that is a differnet topic. This a method to solve a problem that customers have.
Sandeep_K_Shandilya@Dell.com wrote:
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the
discussions about non-free bits in the kernel!
<sandeep> This is not about free and non-free stuff, that is a differnet topic.
I've been having trouble discovering just what I would be getting should I buy a Dell server, and your technique could well be used to mask non-free software.
I've been using Linux for about ten years now, and I've become accustomed to doing things a certain way. I become uncomfortable when a vendor wants to do things differently, and I really do not like phone-home software.
This a method to solve a problem that customers have.
To further clarify things in my mind, I went to Dell.au's website and chose a server we might conceivably buy where I work. I settled on a Poweredge R300.
Then I went to the support page and found me a download for RHEL5. I'm actually running Scientfic Linux 5 on my desktop, so it's a fair comparison. I figure that what I find on the website's probably about what I'd be getting from Dell for that system.
I then tried to investigate the package's contents. It was tricky, my enquiries were about this successful. 09:16 [summer@numbat ~]$ rpm -qp downloads/sg-3[1].5.34dell-1dkms.noarch.rpm --scripts 09:16 [summer@numbat ~]$
That is, no output. So I tried to test installing it: 09:16 [summer@numbat ~]$ sudo rpm -i --test downloads/sg-3[1].5.34dell-1dkms.noarch.rpm Password: error: File not found by glob: downloads/sg-3[1].5.34dell-1dkms.noarch.rpm 09:18 [summer@numbat ~]$
Okay, a bug in rpm. I did better when I renamed the file:
09:19 [summer@numbat ~]$ rpm -qlip sg.rpm Name : sg Relocations: (not relocatable) Version : 3.5.34dell Vendor: (none) Release : 1dkms Build Date: Wed Jun 13 23:40:10 2007 Install Date: (not installed) Build Host: berlin-4-hem Group : System/Kernel Source RPM: sg-3.5.34dell-1dkms.src.rpm Size : 84574 License: Unknown Signature : (none) Packager : DKMS dkms-devel@lists.us.dell.com Summary : sg 3.5.34dell dkms package Description : Kernel modules for sg 3.5.34dell in a DKMS wrapper. /usr/src/sg-3.5.34dell /usr/src/sg-3.5.34dell/sg-3.5.34dell-mktarball.dkms.tgz 09:19 [summer@numbat ~]$
So if I understand you correctly, this is pretty much what you'd be putting in the driver storage.
I unpacked the rpm using rpm2cpio and find both a prebuilt kernel module, and what looks to be the source to recreate it.
In this case we have a standard GPL-licenced Linux driver, with a one-line Dell patch.
I suppose the system was certified at RHEL5.0. If it worked with RHEL5.0 then I don't see the need for RHEL5.0 drivers in usb-storage, unless RH declined to accept the patch, so I suppose that it was certified with this patch in place and that I'd need it to install RHEL5.0 and maybe CentOS5.0 and SL5.0.
Supposing my suppositions are all well-founded, then it would be good to have the driver in USB storage, I'm very good at losing CDs, and even without that skill, where I work most of our computers are three years old before we get them (but then, in such a case, it would be reasonable to expect not to need the Dell driver).
I'm still not keen on the idea of DKMS, it'd rather not be expected to maintain a C compiler on a server.
I would prefer a yum repo at Dell, together with instructions for pinning so one gets only the Dell bits from Dell, but getting the updates from RH etc would be even better.
Hello John
Well I am back, after a bout of sickness :(
Read inline.
Regards, Sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Friday, March 28, 2008 6:17 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
Sandeep_K_Shandilya@Dell.com wrote:
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the
discussions about non-free bits in the kernel!
<sandeep> This is not about free and non-free stuff, that is a differnet topic.
I've been having trouble discovering just what I would be getting should I buy a Dell server, and your technique could well be used to mask non-free software.
I've been using Linux for about ten years now, and I've become accustomed to doing things a certain way. I become uncomfortable when a vendor wants to do things differently, and I really do not like phone-home software.
<sandeep> There are lots of people who call Dell asking for drivers when they fail to install an OS and anaconds says no harddisks found when it does not find the drivers for disk controllers. The two approaches we could take to fix this 1. The method we are discussing in this email 2. get the driver into a future update of the OS( we are already doing this), we still need 1 to take care of the problem currently.
This a method to solve a problem that customers have.
To further clarify things in my mind, I went to Dell.au's website and chose a server we might conceivably buy where I work. I settled on a Poweredge R300.
Then I went to the support page and found me a download for RHEL5. I'm actually running Scientfic Linux 5 on my desktop, so it's a fair comparison. I figure that what I find on the website's probably about what I'd be getting from Dell for that system.
I then tried to investigate the package's contents. It was tricky, my enquiries were about this successful. 09:16 [summer@numbat ~]$ rpm -qp downloads/sg-3[1].5.34dell-1dkms.noarch.rpm --scripts 09:16 [summer@numbat ~]$
That is, no output. So I tried to test installing it: 09:16 [summer@numbat ~]$ sudo rpm -i --test downloads/sg-3[1].5.34dell-1dkms.noarch.rpm Password: error: File not found by glob: downloads/sg-3[1].5.34dell-1dkms.noarch.rpm 09:18 [summer@numbat ~]$
Okay, a bug in rpm. I did better when I renamed the file:
09:19 [summer@numbat ~]$ rpm -qlip sg.rpm Name : sg Relocations: (not relocatable) Version : 3.5.34dell Vendor: (none) Release : 1dkms Build Date: Wed Jun 13 23:40:10 2007 Install Date: (not installed) Build Host: berlin-4-hem Group : System/Kernel Source RPM: sg-3.5.34dell-1dkms.src.rpm Size : 84574 License: Unknown Signature : (none) Packager : DKMS dkms-devel@lists.us.dell.com Summary : sg 3.5.34dell dkms package Description : Kernel modules for sg 3.5.34dell in a DKMS wrapper. /usr/src/sg-3.5.34dell /usr/src/sg-3.5.34dell/sg-3.5.34dell-mktarball.dkms.tgz 09:19 [summer@numbat ~]$
So if I understand you correctly, this is pretty much what you'd be putting in the driver storage.
I unpacked the rpm using rpm2cpio and find both a prebuilt kernel module, and what looks to be the source to recreate it.
In this case we have a standard GPL-licenced Linux driver, with a one-line Dell patch.
I suppose the system was certified at RHEL5.0. If it worked with RHEL5.0 then I don't see the need for RHEL5.0 drivers in usb-storage, unless RH declined to accept the patch, so I suppose that it was certified with this patch in place and that I'd need it to install RHEL5.0 and maybe CentOS5.0 and SL5.0.
Supposing my suppositions are all well-founded, then it would be good to have the driver in USB storage, I'm very good at losing CDs, and even without that skill, where I work most of our computers are three years old before we get them (but then, in such a case, it would be reasonable to expect not to need the Dell driver).
I'm still not keen on the idea of DKMS, it'd rather not be expected to maintain a C compiler on a server. < sandeep > We have binary versions for the drivers too then you will not need the C compilers on the server.
I would prefer a yum repo at Dell, together with instructions for pinning so one gets only the Dell bits from Dell, but getting the updates from RH etc would be even better. <sandeep> That's a good idea for distributing drivers for hardware, it will work good for system already installed or partially installed and on the network. but what about the scenario when you will need a driver to recognise the new hardware (disk controller or NIC) to install the OS?
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
Well I am back, after a bout of sickness :(
:-((
I was wondering about you.
I've been using Linux for about ten years now, and I've become accustomed to doing things a certain way. I become uncomfortable when a vendor wants to do things differently, and I really do not like phone-home software.
<sandeep> There are lots of people who call Dell asking for drivers when they fail to install an OS and anaconds says no harddisks found when it does not find the drivers for disk controllers. The two approaches we could take to fix this 1. The method we are discussing in this email 2. get the driver into a future update of the OS( we are already doing this), we still need 1 to take care of the problem currently.
Surely, if you certify for RHEL5.1 (substitute any vendor's release) this problem will not happen on RHEL5.1.
Surely, if your driver's in the official kernel, it won't happen on any system, certified or not. If I boot Knoppix, or the systemrescue CD, or systemimager, it will just work.
I bought a new computer yesterday, it's not a Dell. I know that if I try to install the latest Fedora beta on it, that it will not find my disks. I know this because I have another from the same series of models and no 2.6.25 kernel finds its disks though 2.6.24 kernels are fine.
Your solution would not help one bit, it would make things worse.
In the present circumstances I get to kick and scream and generally misbehave at the Fedora project. The most I need to worry about (apart from whether it actually gets fixed) is that it remains filed against the right component.
If the driver was stashed away in some secret spot, then I'd also need to throw my tantrams at the hardware vendor and face the likely consequence a <== it's their fault ===> b
This a method to solve a problem that customers have.
To further clarify things in my mind, I went to Dell.au's website and chose a server we might conceivably buy where I work. I settled on a Poweredge R300.
Then I went to the support page and found me a download for RHEL5. I'm actually running Scientfic Linux 5 on my desktop, so it's a fair comparison. I figure that what I find on the website's probably about what I'd be getting from Dell for that system.
I then tried to investigate the package's contents. It was tricky, my enquiries were about this successful. 09:16 [summer@numbat ~]$ rpm -qp downloads/sg-3[1].5.34dell-1dkms.noarch.rpm --scripts 09:16 [summer@numbat ~]$
That is, no output. So I tried to test installing it: 09:16 [summer@numbat ~]$ sudo rpm -i --test downloads/sg-3[1].5.34dell-1dkms.noarch.rpm Password: error: File not found by glob: downloads/sg-3[1].5.34dell-1dkms.noarch.rpm 09:18 [summer@numbat ~]$
Okay, a bug in rpm. I did better when I renamed the file:
09:19 [summer@numbat ~]$ rpm -qlip sg.rpm Name : sg Relocations: (not relocatable) Version : 3.5.34dell Vendor: (none) Release : 1dkms Build Date: Wed Jun 13 23:40:10 2007 Install Date: (not installed) Build Host: berlin-4-hem Group : System/Kernel Source RPM: sg-3.5.34dell-1dkms.src.rpm Size : 84574 License: Unknown Signature : (none) Packager : DKMS dkms-devel@lists.us.dell.com Summary : sg 3.5.34dell dkms package Description : Kernel modules for sg 3.5.34dell in a DKMS wrapper. /usr/src/sg-3.5.34dell /usr/src/sg-3.5.34dell/sg-3.5.34dell-mktarball.dkms.tgz 09:19 [summer@numbat ~]$
So if I understand you correctly, this is pretty much what you'd be putting in the driver storage.
I unpacked the rpm using rpm2cpio and find both a prebuilt kernel module, and what looks to be the source to recreate it.
In this case we have a standard GPL-licenced Linux driver, with a one-line Dell patch.
I suppose the system was certified at RHEL5.0. If it worked with RHEL5.0 then I don't see the need for RHEL5.0 drivers in usb-storage, unless RH declined to accept the patch, so I suppose that it was certified with this patch in place and that I'd need it to install RHEL5.0 and maybe CentOS5.0 and SL5.0.
Supposing my suppositions are all well-founded, then it would be good to have the driver in USB storage, I'm very good at losing CDs, and even without that skill, where I work most of our computers are three years old before we get them (but then, in such a case, it would be reasonable to expect not to need the Dell driver).
I'm still not keen on the idea of DKMS, it'd rather not be expected to maintain a C compiler on a server. < sandeep > We have binary versions for the drivers too then you will not need the C compilers on the server.
The new computer I mentioned a few minutes ago won't be running Fedora, but I have one like it that does.
Do you track each new Fedora kernel?
What about each new Rawhide kernel?
Or even each new Fedora/Rawhide install image.
Let's assume I buy a Dell system; sales have been a bit sluggish and I get a good deal because the system's a bit old, maybe it's previous to the current model. It might be certified for RHEL5.0, but what if I want to install RHEL 5.2 on it?
This is all solved if the source is in the official kernel.
One of the things I prefer about Windows is that a driver for Windows XP most likely works for all releases of Windows XP. But, I don't suppose Linus and the others will change on my account.
I would prefer a yum repo at Dell, together with instructions for pinning so one gets only the Dell bits from Dell, but getting the updates from RH etc would be even better.
<sandeep> That's a good idea for distributing drivers for hardware, it will work good for system already installed or partially installed and on the network. but what about the scenario when you will need a driver to recognise the new hardware (disk controller or NIC) to install the OS?
It would provide an easy-to-find place to look, maybe you could host all your repost at linux.dell.com where people could find the drivers for their favourite hardware.
It would be near perfect for any utility software Dell provides.
Hello John
Your point about using this technique to mask non-free software is a good one, yes it is possible to do it. But then the same could be achieved in other ways too. I think what is good for the end customer is what open source is all about.
Regards, Sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of John Summerfield Sent: Friday, March 28, 2008 6:17 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
Sandeep_K_Shandilya@Dell.com wrote:
I'm not sure that DELL would provide full support for RHEL, or even the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the
discussions about non-free bits in the kernel!
<sandeep> This is not about free and non-free stuff, that is a differnet topic.
I've been having trouble discovering just what I would be getting should I buy a Dell server, and your technique could well be used to mask non-free software.
I've been using Linux for about ten years now, and I've become accustomed to doing things a certain way. I become uncomfortable when a vendor wants to do things differently, and I really do not like phone-home software.
This a method to solve a problem that customers have.
To further clarify things in my mind, I went to Dell.au's website and chose a server we might conceivably buy where I work. I settled on a Poweredge R300.
Then I went to the support page and found me a download for RHEL5. I'm actually running Scientfic Linux 5 on my desktop, so it's a fair comparison. I figure that what I find on the website's probably about what I'd be getting from Dell for that system.
I then tried to investigate the package's contents. It was tricky, my enquiries were about this successful. 09:16 [summer@numbat ~]$ rpm -qp downloads/sg-3[1].5.34dell-1dkms.noarch.rpm --scripts 09:16 [summer@numbat ~]$
That is, no output. So I tried to test installing it: 09:16 [summer@numbat ~]$ sudo rpm -i --test downloads/sg-3[1].5.34dell-1dkms.noarch.rpm Password: error: File not found by glob: downloads/sg-3[1].5.34dell-1dkms.noarch.rpm 09:18 [summer@numbat ~]$
Okay, a bug in rpm. I did better when I renamed the file:
09:19 [summer@numbat ~]$ rpm -qlip sg.rpm Name : sg Relocations: (not relocatable) Version : 3.5.34dell Vendor: (none) Release : 1dkms Build Date: Wed Jun 13 23:40:10 2007 Install Date: (not installed) Build Host: berlin-4-hem Group : System/Kernel Source RPM: sg-3.5.34dell-1dkms.src.rpm Size : 84574 License: Unknown Signature : (none) Packager : DKMS dkms-devel@lists.us.dell.com Summary : sg 3.5.34dell dkms package Description : Kernel modules for sg 3.5.34dell in a DKMS wrapper. /usr/src/sg-3.5.34dell /usr/src/sg-3.5.34dell/sg-3.5.34dell-mktarball.dkms.tgz 09:19 [summer@numbat ~]$
So if I understand you correctly, this is pretty much what you'd be putting in the driver storage.
I unpacked the rpm using rpm2cpio and find both a prebuilt kernel module, and what looks to be the source to recreate it.
In this case we have a standard GPL-licenced Linux driver, with a one-line Dell patch.
I suppose the system was certified at RHEL5.0. If it worked with RHEL5.0 then I don't see the need for RHEL5.0 drivers in usb-storage, unless RH declined to accept the patch, so I suppose that it was certified with this patch in place and that I'd need it to install RHEL5.0 and maybe CentOS5.0 and SL5.0.
Supposing my suppositions are all well-founded, then it would be good to have the driver in USB storage, I'm very good at losing CDs, and even without that skill, where I work most of our computers are three years old before we get them (but then, in such a case, it would be reasonable to expect not to need the Dell driver).
I'm still not keen on the idea of DKMS, it'd rather not be expected to maintain a C compiler on a server.
I would prefer a yum repo at Dell, together with instructions for pinning so one gets only the Dell bits from Dell, but getting the updates from RH etc would be even better.
Sandeep_K_Shandilya@Dell.com wrote:
Hello John
Your point about using this technique to mask non-free software is a good one, yes it is possible to do it. But then the same could be
It's a fairly obvious concern.
achieved in other ways too. I think what is good for the end customer is what open source is all about.
Good. You know the best way to alleviate that concern.
Hello Bill
My comments inline.
regards, sandeep.
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] On Behalf Of Bill Nottingham Sent: Monday, March 17, 2008 8:14 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: [ PATCH ] RFC: Search and load drivers automatically fromusb-storage media
Sandeep_K_Shandilya@Dell.com (Sandeep_K_Shandilya@Dell.com) said:
- 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.
Imagine trying to search 500 SAN partitions for driver updates. <sandeep> We look good at this point because storage drivers are not yet loaded. The only driver that is loaded is the usb-storage driver and the ide disk driver.
- 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...
Right, but what good does embedded usb-storage with drivers do you for the next OS release a few months later? <sandeep> Dell baselines do not align with redhat updates. Redhat releases updates every 6 months But Dell baselines on an OS every 1 and half ot 2 years Eg, rhel 4.0 and rhel 4.5. In the interim we also get the drivers updated in the next available update.
Bill
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mon, Mar 17, 2008 at 01:39:29PM +0530, Sandeep_K_Shandilya@Dell.com 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.
- 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?)
- 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.
Hello
My comments inline <sandeep>
-----Original Message----- From: anaconda-devel-list-bounces@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] 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@Dell.com 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.
- 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.
- 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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
David Cantrell -
John Summerfield -
Ragnar Kjørstad -
Sandeep_K_Shandilya＠Dell.com