Craig Russell wrote:
It was recommended that I *NOT* use initrd unless I absolutely had a
reason (booting from LVM or raid, etc) but all of the debian images
come in this manner and I have been unable to compile a kernel and
get it to boot without initrd. Am I missing something?
I could be missing something but I have always associated ramdisks with
modules and stock installation kernels, because with the ramdisk the
kernel
doesn't need a block device or other peripherals to be running while the
OS probes the hardware or get hardware information from the user. I
guess
it's there in the stock kernel so that the same kernel can be used to
by the
install media.
Other uses include rescue/utility disks and filesystem image manipulation
like CD-ROM burning. I don't see any need for the average user to
have it
in their custom kernel unless you need to burn CD-ROMs or are creating a
standalone kernel specifically for diagnostics purposes, e.g. for use in
a custom utility or rescue floppy, USB drive or CD-ROM (i.e. something
that
has to be able to boot up on any machine).
At some point I will be
attempting to mirror the boot disk so I will need initrd anyway
I don't see how that will help. Tar, rsync or cp should be sufficient.
so I
don't mind having to set it up but is it required for all kernels or
is there a way to not use it?
Not as far as my needs are concerned. I've compiled custom kernels for
rescue floppies but that's all.
As a -semi-related aside, does anyone remember any LKML messages where
Linus
seems to be exasperated and periodically threatens to deprecate modules
because people were getting so dependant on them? I agreed with him, but
he could have been joking or I could be "misremembering" it. I thought
the idea was that modules (and therefore most uses of initrd) are
obsolete
anyway.
Thanks,
Craig Russell
AirDigitalNetwork.com