booting a modular kernel
I tried compiling a kernel from source---I know SuSE officially discourages anything but the standard distro kernel, but I've enjoyed kernels compiled specifically for the machine in the past, and if I want to patch a kernel for whatever reason, I'll need to compile, etc. This machine runs from a scsi bus, so it needs to use initrd during boot if the scsi driver is configured as a module. That's the way the SuSE 6.3 2.2.13 kernel is configured, and that's the way I configured the new one. Naturally, I want to keep my old, working kernel in place as a backup. I need to know how to use mk_initrd, if necessary, to make the ramdisk image for the new kernel, but I need also to know what to do to preserve the /boot/initrd image for my old kernel. SuSE 6.3 came with no documentation on mk_initrd; there's an ancient man page for initrd, from 1997, but it doesn't provide any real help for mk_initrd. Invoking mk_initrd with --help gives "usage: mk_initrd [root_dir]" which doesn't give me much help in supporting two kernels. RedHat's version, called mkinitrd, is significantly different from SuSE's mk_initrd. Maybe it's possible I can use the same /boot/initrd image for all kernels, but so far, I can't seem to make it work---every configuration I've tried ends with a kernel panic: "VFS: Cannot open root device 08:02" which is the root partition on the scsi hard disk. rdev gives the same info for both the old and new kernels. Has anyone successfully compiled (and run) a kernel on a SuSE system? Have you done it in a situation where initrd was necessary? Does anyone have any documentation on mk_initrd? TIA, Jim
On Mon, May 07, 2001 at 10:43:22PM -0700, Jim Osborn wrote:
Has anyone successfully compiled (and run) a kernel on a SuSE system?
Have you done it in a situation where initrd was necessary?
Yes, yes but not really. I highly recommend compiling the SCSI support directly into the kernel, and dispensing with the need for initrd. In my opinion, initrd is a great idea for when you sell a Linux distribution with a precompiled kernel and need to decide at installation time what hardware needs to be supported on boot. But if you're going to go and install a custom kernel, you might as well compile support for your boot drive directly into the kernel. Saves a lot of pain and frustration. For the record, I think you can't use the same initrd you had before because its kernel modules are compiled for your previous kernel, and modules compiled with kernel A will generally not work with kernel B. -tara
* Tara L Andrews [Tue, 8 May 2001 02:01:45 -0400]:
In my opinion, initrd is a great idea for when you sell a Linux distribution with a precompiled kernel and need to decide at installation time what hardware needs to be supported on boot
That's not the only reason for using an initrd. Another one is, that the kernel created is too large to fit on the installation boot disk. We did have that problem with the 2.4 kernels and so compiled reiserfs as a module which gets loaded via initrd. Another one would be the need to run the isapnp tool to configure ISA PnP cards for a 2.2 kernel. That could be done from an initrd. My experience is, that initrds are rather easy to use and eliminate the need to compile a kernel. Of cause the benefit for a Linux distributor like us is much higher. In the olden days we had to offer 20+ kernels, all compiled with different SCSI drivers. That prohibited offering SMP and Pentium optimized kernels as the number of kernels we would have to provide would have exploded. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
Hello, On Tue, 8 May 2001, Philipp Thomas wrote:
* Tara L Andrews [Tue, 8 May 2001 02:01:45 -0400]:
In my opinion, initrd is a great idea for when you sell a Linux distribution with a precompiled kernel and need to decide at installation time what hardware needs to be supported on boot
That's not the only reason for using an initrd. Another one is, that the kernel created is too large to fit on the installation boot disk. We did have that problem with the 2.4 kernels and so compiled reiserfs as a module which gets loaded via initrd.
Another one would be the need to run the isapnp tool to configure ISA PnP cards for a 2.2 kernel. That could be done from an initrd.
My experience is, that initrds are rather easy to use and eliminate the need to compile a kernel. Of cause the benefit for a Linux distributor like us is much higher. In the olden days we had to offer 20+ kernels, all compiled with different SCSI drivers. That prohibited offering SMP and Pentium optimized kernels as the number of kernels we would have to provide would have exploded.
-- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
I have one question. What do you mean by Pentium optimized kernel? Do you write some sort of kernel code for this purpose? Regards. Erdal MUTLU
* Erdal MUTLU Arastirma Gorevlisi [Tue, 8 May 2001 11:47:22 +0300 (EEST)]:
I have one question. What do you mean by Pentium optimized kernel? Do you write some sort of kernel code for this purpose?
No. The kernel can be configured for different processors. This will pass appropriate flags to the compiler telling it for which processor it should optimise. The compiler then chooses the optimum instructions and tunes the scheduling of code. And the kernel sources contain a few places where different inline assembly code is used depending on the processor its compiled for. So we don't add any source code but just use what the kernel offers. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
Jim Osborn wrote:
Naturally, I want to keep my old, working kernel in place as a backup. I need to know how to use mk_initrd, if necessary, to make the ramdisk image for the new kernel, but I need also to know what to do to preserve the /boot/initrd image for my old kernel.
Just copy it to a different name below /boot and add a corresponding entry to /etc/lilo.conf. This way, mk_initrd will not touch the old initrd anymore, but lilo will still use it.
From my lilo.conf: # image = /boot/vmlinuz-2.2.19-SMP root = /dev/sda6 label = 2.2.19-SMP initrd = /boot/initrd-2.2.19-SMP
[I also copy the vmlinuz kernel images to non-standard names, here: vmlinuz-2.2.19-SMP.]
Maybe it's possible I can use the same /boot/initrd image for all kernels, but so far, I can't seem to make it work---every configuration I've tried ends with a kernel panic: "VFS: Cannot open root device 08:02" which is the root partition on the scsi hard disk. rdev gives the same info for both the old and new kernels. Looks like the required scsi-module is missing.
Try to add the required modules to your /etc/rc.config's INITRD_MODULES (mk_initrd picks them up from therein). Eg. mine looks like this (SCSI-only System)
# # The module for initrd during boot # INITRD_MODULES="sym53c8xx usbcore"
Also run: mk_initrd lilo after having compiled a new kernel. This will rebuild a couple of initrds, and makes sure that lilo will be picking up the correct ones.
Has anyone successfully compiled (and run) a kernel on a SuSE system? Guess?
Does anyone have any documentation on mk_initrd? mk_initrd is a fairly simple shell script - read it!
Ralf
* Jim Osborn [Mon, 7 May 2001 22:43:22 -0700 (PDT)]:
I tried compiling a kernel from source---I know SuSE officially discourages anything but the standard distro kernel,
We don't discourage it, we just don't support it. That's a whole different matter.
Naturally, I want to keep my old, working kernel in place as a backup. I need to know how to use mk_initrd, if necessary, to make the ramdisk image for the new kernel, but I need also to know what to do to preserve the /boot/initrd image for my old kernel.
Just create different configurations in /etc/lilo.conf. Something like this: image = /boot/vmlinuz label = linux root = /dev/sda3 initrd = /boot/initrd image = /boot/vmlinuz-2.4.4 label = lx244 root = /dev/sda3 initrd = /boot/initrd-2.4.4 If all the modules you need/want are listed in the INITRD_MODULES varaible in /etc/rc.config, run mk_initrd -k "vmlinuz vmlinuz-2.4.4"-i "initrd initrd-2.4.4" As you see, the list of initrds has to match the lists of kernels. Does that suffice? -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
participants (5)
-
Erdal MUTLU Arastirma Gorevlisi -
Jim Osborn -
Philipp Thomas -
Ralf Corsepius -
Tara L Andrews