The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647
Ditto for the uli526x network driver, network installs are impossible on systems using that:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165
The kernel has the drivers available, but people are reporting these as kernel bugs...
Chuck Ebbert (cebbert@redhat.com) said:
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647
Ditto for the uli526x network driver, network installs are impossible on systems using that:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165
The kernel has the drivers available, but people are reporting these as kernel bugs...
module-info in the anaconda package.
Bill
On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote:
Chuck Ebbert (cebbert@redhat.com) said:
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647
Ditto for the uli526x network driver, network installs are impossible on systems using that:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165
The kernel has the drivers available, but people are reporting these as kernel bugs...
module-info in the anaconda package.
I should get back to trying to auto-generate this now that we have the modules.scsi, etc files in place...
Jeremy
Jeremy Katz (katzj@redhat.com) said:
On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote:
Chuck Ebbert (cebbert@redhat.com) said:
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647
Ditto for the uli526x network driver, network installs are impossible on systems using that:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165
The kernel has the drivers available, but people are reporting these as kernel bugs...
module-info in the anaconda package.
I should get back to trying to auto-generate this now that we have the modules.scsi, etc files in place...
I have code working for this at the moment... however, it seems wrong.
Right now it's based on the modules.scsi, modules.networking, etc. that are shipped in very very recent kernel packages. Looking at how it's done now, we have:
# Generate a list of modules for SCSI, sata/pata, and networking. touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking for i in `cat modnames | grep drivers | grep -v drivers/ata` do if [ $(nm $i |grep --count scsi_add_host) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done for i in `cat modnames | grep drivers | grep -v drivers/scsi` do if [ $(nm $i |grep --count blk_init_queue) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done
for i in `cat modnames | grep drivers/ata` do if [ $(nm $i |grep --count ata_device_add) -ne 0 -o $(nm $i |grep --count ata_pci_init_one) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata fi done
for i in `cat modnames |grep drivers` do if [ $(nm $i |grep --count register_netdev) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking fi done
in the kernel spec file. This has the following issues:
1) it's not complete (relatively easily fixed, but leads to...) 2) you can't ever fix the list for kernels that have these lists wrong without rebuilding them. That's bad. 3) anything that uses this will never work on a) older kernels b) 'upstream' kernels, etc. 4) there's a rather arbitrary ata vs. scsi distinction here that seems solely designed to cull the module list for the live CD. Seems strange to me.
Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation.
Bill
On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote:
Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation.
It can be done in module-init-tools, and probably should be. Let me take a look.
Jon.
Jon Masters (jcm@redhat.com) said:
On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote:
Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation.
It can be done in module-init-tools, and probably should be. Let me take a look.
Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules.
Bill
On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote:
Jon Masters (jcm@redhat.com) said:
On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote:
Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation.
It can be done in module-init-tools, and probably should be. Let me take a look.
Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules.
I'm thinking about it ;-)
Jon.
On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote:
Jon Masters (jcm@redhat.com) said:
On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote:
Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation.
It can be done in module-init-tools, and probably should be. Let me take a look.
Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules.
When davej and I talked about it, we decided "probably not". And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it
Jeremy
Jeremy Katz (katzj@redhat.com) said:
Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules.
When davej and I talked about it, we decided "probably not". And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it
But that means any time the symbol list changes, you'll need to rebuild the kernel ; you effectively have a DOA kernel for the installer. If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours.
Bill
On Fri, 2007-07-27 at 13:43 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules.
When davej and I talked about it, we decided "probably not". And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it
But that means any time the symbol list changes, you'll need to rebuild the kernel ; you effectively have a DOA kernel for the installer.
Lots of things can lead to a DOA kernel. It's not like the symbols we're talking about here are things that change frequently. And it's more likely to actually get *done* if it's in the same place that the changes occur. Otherwise, no one's going to tell us that the symbol list changed until someone happens and we're in exactly the same place we are now. There is zero reason why this information should be maintained within the installer,etc
If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours.
There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there
Jeremy
Jeremy Katz (katzj@redhat.com) said:
If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours.
There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there
In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here.
Bill
On Fri, 2007-07-27 at 14:03 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours.
There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there
In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here.
Depends on how many copies of the qlogic driver there are ;-) Especially since we'll have to be pulling in firmware, etc eventually.
I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here
Jeremy
Jeremy Katz (katzj@redhat.com) said:
Depends on how many copies of the qlogic driver there are ;-)
RHEL live CDs? What's that?
(Actually, I lied - drivers/block + drivers/scsi is 1.3M compressed.)
I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here
OK. I'll tweak the stuff in the spec and send it here for comments.
Bill
Bill Nottingham (notting@redhat.com) said:
I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here
OK. I'll tweak the stuff in the spec and send it here for comments.
Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers.
Bill
Bill Nottingham (notting@redhat.com) said:
Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers.
... committed.
Bill
On Wed, Aug 01, 2007 at 03:22:16PM -0400, Bill Nottingham wrote:
Bill Nottingham (notting@redhat.com) said:
Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers.
... committed.
Bah, missing %files entries for modules.block Fixed it up.
Dave
kernel@lists.fedoraproject.org