> /etc/rc.d/rc.sysinits now looks for the kernel
> name in /etc/lilo.conf, it
> also checks it with /boot/vmlinuz, and also with
> lilo -I. Look at the code
> starting on line 114 in rc.sysinit.
I don't know much about shell scripting and nothing about
awk and sed, so I don't think I have worked out exactly what
is going on in rc.sysinit. It looks like it:
1. Extracts the name of the BOOT_IMAGE from /proc/cmdline;
2. Runs lilo -I against this name to find the filename and
path to the kernel;
3. Extracts the kernel name and version from this result;
4. Tests to see whether the kernel name matches
"/boot/vmlinuz" and a directory exists for the version
number under /lib/modules and that this version number
matches the actual version (given by uname) of the kernel;
5. If the test succeeds, creates a symlink from the version
number to /lib/modules/preferred;
6. Tests to see whether /lib/modules/preferred exists;
7. Whether it does or doesn't, does "depmod -a preferred" to
create modules.dep in the preferred directory
But I must be wrong about this because:
(a) RedHat wouldn't force every kernel to be called
/boot/vmlinuz-???
(b) The name of the kernel would be a crazy place to extract
information about the version of the kernel
(c) "ln -sf $versioninfo /lib/modules/preferred" would
create a symlink within the current directory, not
necessarily in /lib/modules/
(d) They wouldn't "depmod -a preferred" if they had just
tested that /lib/modules/preferred didn't exist
Or would they?
I don't really care how the script works. I just want
kerneld to be able to load the appropriate modules when they
are needed. What do I need to do differently to earlier
versions of RedHat when I am compiling a kernel with
modules? Or having built a kernel and installed the modules
in /lib/modules/2.0.34, what can I do besides hacking
rc.sysinit to get depmod to work during boot-up?
On a more general level, the system wasn't broke before, so
why did they "fix" it? And if you're going to "fix"
something, shouldn't you at least try to avoid introducing
unnecessary errors and incompatibilities? And if you do
introduce problems into a system where there were none
before, shouldn't you at least provide easily visible
documentation on the changes and how to work around them? Or
do RedHat exist in a separate universe where the basics of
software development and support are inverted?
Cheers,
Bruno Prior [EMAIL PROTECTED]
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
