Originally posted by budzynm
That's good -- but obviously we had to check that you do have the modules compiled and installed that you actually need.
alias block-major-17 off
..and so on for the items that have been giving me the errors
However, two interesting things happen:
1. When I went to shut down and startup modprobe noted to me that modules.conf is more recent than modules.dep
2. The errors came back, even with the 'alias block-major-X off' (quotes mine)
That is because modules.dep is more recent than module.conf.
To correct this error (apologies for my omission) you need to do a
which updates the modules.dep file using information in the modules.conf file.
My excuse is I thought that in one of the /etc/init.d scripts it always did a depmod -a for you, but perhaps that has been added since the RedHat 7 which you are using.
So if you do that and try rebooting again, hopefully those annoying messages should for the most part be silenced.
My question: Is the modules.dep controlling what modules are trying to be located by modprobe?
Yes exactly! And not only that, they list the dependencies on each module.
So if you do a
modprobe -a some_module
(note you have to use the -a , automatically load up dependent modules)
then it will insmod all of the modules you need, not just the one you specified.
[QUOT]If that's true does that mean that when I configured my kernel I must have omitted something?[/QUOTE]
No. If you had omitted something necessary, then something would be broken and you claimed that all was working as it should.
As far as I know here is why those error messages appear, and as far as I know, they appear not because of the kernel booting but because an executable program called in /etc/init.d/script is being called.
A program is to be executed but the program needs to access a device. So first of all the module loading program, if the device is not turned off in the modules.conf file, tries to find a module to load. This fails because the module does not exist so an error message is issued. However the support for the device is already included in the monolithic kernel, hence the program works.
If I cross-index /usr/src/linux/Documentation/devices.txt with modules.dep will I be able to figure out which modules are causing my errors?
You got it!!! When I was getting all my messages I eventually found out by searching with Google that I could find out to what "char-major-188" or whatever was actually referring. There was a file which listed all of these numbers and that was /usr/src/linux/Documentation/devices.txt. So error message by error message I went through the numbers and discovered that for all of them, they were devices that I did not have on my system or that I had compiled into the monolithic kernel.
If that's true then I can go back to xconfig and make sure I correct those options.
Exactly - you have fully understood the scheme of things!
Either you do not have the physical device or it is compiled into the kernel.
Just a point of information, but how are these numbers actually used?
Well remember you have a /dev directory and that you use
with a major number and either a character or block device?
Well in userspace, programs use the character name of the device eg /dev/dsp, /dev/hda, but these are pointers to device node numbers (dsp is 14, nvidia is 195)
So if you go to the source code for the device driver module, you will see lines in the C code similar to --
nv.h:#define NV_MAJOR_DEVICE_NUMBER 195
nv.c:int nv_major = NV_MAJOR_DEVICE_NUMBER;
nv.c: rc = devfs_register_chrdev(nv_major, "nvidia", &nv_fops);
nv.c: rc = register_chrdev(nv_major, "nvidia", &nv_fops);
Hopefully you now see how the kernel modules and the device files are related.