Kernel compile problems

[Robert Dege]

My kernel compile (on the new machine) existed because of the entries in
the modules.conf file.  I remember this _NOT_ occurring in the past on
older systems (like my 7.1 system), so I'm assuming this is new initrd
"functionality".

Also, Redhat uses the initrd image to read & mount the root label /, vs
the actual device (/dev/hda1).  I found that out upon reboot ;)

Thanks for all the help!

-Rob

>
> --- "Kevin E. Glosser" <keg at adelphia.net> wrote:
> > On Fri, 2003-07-11 at 13:52, Dave Andruczyk wrote:
> > > initial ramdisks are ONLY needed
> >
> > I find it interesting that the Redhat 9.0 installer opts for using this.
> > Any idea why? Does it need it for installation purposes? When I rebuilt
> > my kernel afterwards, I decided to get rid of it.
> >
>
> I think redhat just does it mainly for historical reasons. ( I think they were
> one of the first to use initrd), and so they can build a GeneralPurpose kernel
> that works on the widest range of systems and only require mkinitrd to be run
> at the end of install (once all HW is detected) this way for people with SCSI
> systems (like me) all the SCSI drivers don't have to be built in (which makes
> the kernel prohibitively large)
>
> If you only have one or two boxes and you like to "roll your own" kernel, then
> in many cases the initial ramdisk isn't a requirement.  IT just makes the
> distro vendor's job easier. (Only one kernel package needed, just need to make
> sure to run the right set of scripts to get the initrd done right)
>
> > Speaking of rebuilding kernels(something I've always played around
> > with), wouldn't it be cool to have a detailed explanation of EVERY
> > SINGLE kernel option that one encounters when they do a "make
> > xconfig/menuconfig/config"?? The help that comes with these options, I
> > often find lacking. And I am sure, there are a couple things compiled
> > into my kernels that I don't need. Simply because, the explanation was
> > too vague or said nothing at all.
> >
> > Some of the options get fairly technical, and the ones that bother me
> > most, are the archaic bug fix drivers that you never know if you need
> > anymore. "Such and such fixes a bug in x86 motherboards..." Great, at
> > what point was that actually fixed in the hardware and I can stop
> > including it, cause i don't need it?? Sigh.
>
> Sounds like a good enough idea.  Most coders (myself included), tend to do
> documentation last (sometimes if at all...), so I see where the problem lies...
> Might be good if the patch coordinators would not allow a patch unless it comes
> in with adequate docs (esp if it is an optional component)
>
> >
> > > Dave J. Andruczyk
> >
> > Why can't I see your name and NOT think of former Sabres winger Dave
> > Andreychuk?? :)
>
> Most people see my name and pronounce it like his as well. But I don't play
> hockey,  probably never will.... :),  it's more like (Ann-drew-zick in
> poor-mans phonetics... )
>
>
> =====
> Dave J. Andruczyk
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>



Dege

So Many Things in Life Would Be Really Funny
.... If They Weren't Happening To Me