On Tue, 6 Jun 2000, Rodent of Unusual Size wrote:
> So I built a new kernel ... what *should* I name the new kernel?
How about "Fred"? :)
Seriously, the name is completely arbitrary. You can name it anything you
want. You see the generic names "vmlinux" (uncompressed) and "vmlinuz"
(compressed) a lot, but those are simply a (loose) convention.
> The last one is vmlinuz-2.2.12-20; this is the first time I've rebuilt the
> kernel, so from whence does the '-20' come?
That is a Red Hat convention. The "2.2.12" is the kernel version,
obviously. The "20" is the revision of the RPM which packages the bootable
kernel. Every time Red Hat revs their package (to tweak build options, apply
new patches, or whatever), they increment that number.
> Should my new one be named '-21'?
I would say no, as that might conflict with a future Red Hat RPM.
You might name it something like "vmlinux.bz-2.2.12-L1" (the "L" I just made
up; it stands for "Local") if you want to be anal about things (I am).
Alternatively, you could just call it "vmlinubz.local", or "vmlinubz", or even
"fred". Whatever floats your boat.
> How about all the other *-2.2.12-20* files, like the system map and the
> module-info file?
The System.map file is built in the root of the kernel tree (usually
/usr/src/linux/). It contains address-to-name mappings for kernel symbols,
and is used by (among other things) klogd, the kernel log daemon, in the
event of a panic. It isn't critical, but makes error messages more readable
by giving symbol names instead of machine addresses.
module-info is a Red Hat thing. It contains module names, device aliases,
and parameters. Exactly what it is used by, I'm not entirely sure. My guess
is their hardware auto-configuration stuff uses it. In any event, it should be
fairly portable across different kernel versions, so just leave it be.
initrd is the initial ramdisk image. Initial ramdisks are used for (among
other things) when you want to boot a generic, modular kernel, but your root
filesystem is on a device supported by a module. To avoid the chicken-and-egg
problem, a custom ramdisk image is created, local to the system, separate from
the kernel image. If contains any modules needed to boot the system. LILO
loads the kernel and initrd. The initrd is mounted as the root filesystem,
loads the needed modules, and then mounts the "real" root. Since you're
building the needed drivers into the kernel statically, I wouldn't worry about
it.
> It seems to me that formally installing a new kernel is *slightly* more
> involved than just copying over the compressed image ...
Not really. You just have to tell your boot loader (i.e., LILO) about it.
Well, that's not entirely true. If you built some things as modules, you
have an extra step. After the kernel gets done building, you need to copy the
module object files into the "/lib/modules/<kernel_version>/" directory.
This can be done automatically by using "make modules_install" in the kernel
source tree. If you're updating your existing kernel (such that a directory
under /lib/modules already exists for it), you should probably rename the
existing directory first, in case the new compile is totally bogus (wrong
architecture or something like that).
> ... but I don't see the process documented.
We don't need no stinkin' documentation. ;-)
--
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
