"Doug MacFarlane" <[EMAIL PROTECTED]> writes: [snip] > I'm in the process of learning to compile my own kernels, and since > I do everything the Debian way, i'll be a kpkg guy and build .debs > of my custom kernels, which will install in identical fashion, as > the prepackaged kernels.
make-kpkg is a *very* nice piece of software. Makes maintaining your own kernels relatively painless. > That said, as near as I can tell from looking in /boot, when one > installe a kernel in this fashion, everything is still there from > the previous kernel except the symlink from vmlinuz to the kernel or > initrd image, so . . . Actually, I think the default behavior for Debian is to set up /etc/lilo.conf to keep two kernels in the boot menu. The current one you just installed and the old one. This is done using the links /vmlinuz and /vmlinuz.old. So if you were running 2.2.20 (from a default Debian install) and then installed a prepackaged kernel-image-2.4.19 the new kernel package would likely have reset /vmlinuz.old to point to /boot/vmlinuz-2.2.20 and set /vmlinuz to point to /boot/vmlinuz-2.4.19 and if you let the package script run lilo for you, and assuming you have a default /etc/lilo.conf file, you can boot either of those two kernels from the LILO prompt. For a new install, of stable, I think your choices are Linux and LinuxOLD. Of course you can hit TAB (I think) at the LILO prompt and it'll give you the list of possibilities. > Is it possible to have multiple LILO entries to boot different > kernels off of the same /boot partition? My replay above should give you a hint. Yes, you can have as many kernels, of different kernel versions (like 2.2.20, 2.4.18, 2.4.19, etc.), as you want. If you want different kernels of the same kernel version, i.e., you want to install multiple copies of the 2.4.19 kernel, you'll have to look at kernel "flavors" (--append_to_version in newer make-kpkg speak) I believe. Otherwise it will install over any previous kernel of the same kernel version. If you want to have more than two kernels in LILO you'll probably have to set that up yourself by editing /etc/lilo.conf. It'd be easy to do by just copying the already existing Linux and LinuxOLD sections and replacing the appropriate fields to coincide with your kernel, including specifying the kernel image in /boot. > And as a followup, what's the difference between booting a kernel, > and booting an initrd image? Why have the prepackaged kernels moved > to initrd? Why would I want to build my custom kernels to boot as > initrd images? Why wouldn't I? initrd allows pretty much any and all drivers to be built as modules. The bare-bones kernel is then booted, via initrd, and it loads the modules necessary to continue booting your computer, for example your disk controller (IDE, SCSI). This allows you to build a single generic kernel that will boot on pretty much any hardware supported by Linux. In contrast, distributions used to have to build kernels for different drivers. You'd have kernels like kernel-image-2.2.x-idepci, kernel-image-2.2.x-scsi, etc., so that you could install on a specific computer with the specified hardware. They had to do this because building all the necessary drivers into the kernel, so that you could boot on any conceivable hardware, made the kernel too big to fit in memory at boot time. I, personally, don't like using initrd for my own custom kernels. Just adds another layer to the boot process that I'd rather avoid. Since you, in theory, know what you need to compile into your own custom kernel in order to boot your machine you shouldn't need to use initrd. Now if you were maintaining a custom kernel for a large variety of machines it might be worth it so that you could avoid compiling custom kernels for each machine, but that's the only reason I am aware of for using initrd for custom kernels. All of this is to the best of my understanding, and I'm hardly an expert on initrd since I don't use it, so take it with a grain of salt. Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
