[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Initrd or not ? (was: SOLVED: New kernel unable to mount/see a whole HD)

On Tue, 2006-01-03 at 10:09 -0800, Andrew Sackville-West wrote:
> J.F. Gratton wrote:
> > solved, but not at my full satisfaction...
> > 
> > I compiled the kernel with initrd support and it went fine, using a
> > 2.6.12-10 config file.
> > 
> > I therefore voided one of the main gain I wanted by building my own
> > kernel: getting rid of initrd. I still got my own kernel at the time I
> > wanted (ie: not waiting for the distro to issue one), but hey.. one
> > cannot win everywhere :)
> This is something I've wondered about for a while watching various 
> kernel compile threads. What is the purpose of getting rid of initrd? 
> What is the advantage (or dis-, I suppose) of this?
> A

[the following is not flame-bait, just my personal opinion :) ]

Some advantages of initrd are mainly for distros. They don't have to
compile/merge lots of drivers into the kernel image when they provide an
install cd/dvd . That way they can "modularize" (if that word exists)
their kernels instead of relying on big monolithic thingies at install.
This way, having all your IDE/SCSI layer (to name one part of the
kernel) in a RAM Disk, you don't have to worry of what type of hardware
your recipient is using. Cram everything into a initrd as modules, and
that's it.

Some disadvantages, in my view :
- More dependencies to take into account when building your kernel (you
need tools like initrd-tools or initramfs-tools on top of your current
toolchain. For a glimpse of the current problems you might encounter
when building an initrd:

(they both point to 2 bugs registered at debian.org; you might want to
see those)

- A few more steps to build your kernel; ok, that is no big deal,
really, but if one can avoid it.. why not ?
- I know my hardware, it's unlikely to change in a near-future; a new
kernel is more likely to come out thant my hardware to change; why using
an initrd then if I know exactly what needs to be put in modules and
must not ?

Other people might come up with better ways to explain what I think, or
other reasons to love/loathe initrd. It's up to them :)

-- Jeff

Reply to: