Kernel compile problems

Robert Dege rdege at cse.Buffalo.EDU
Fri Jul 11 17:29:08 EDT 2003

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

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!


> --- "Kevin E. Glosser" <keg at> 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


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

More information about the nflug mailing list