Re: debian boot CDs & G5
On Wed, May 26, 2004 at 12:06:45PM +0200, Gaudenz Steinlin wrote:
> On Wed, May 26, 2004 at 07:47:47AM +0200, Sven Luther wrote:
> > On Tue, May 25, 2004 at 10:22:25PM +0200, Jens Schmalzing wrote:
> > > No. The initrd should only contain the modules needed for bringing up
> > > the root filesystem, and maybe using the console. It is mkinitrd's
> > > duty to figure out what's needed. If the resulting initrd doesn't
> > > work, it's a bug in mkinitrd and needs to be fixed.
> >
> > Yeah, sure, but i think there is a misunderstanding. the duty of
> > discover is exactly to find the modules needed by your system and load
> > them. Exactly the same thing mkinitrd does (or more exactly the the
> > /bin/init script of the initrd), just in a bigger scale. It is my
> > understanding that if discover is used together with a smaller database
> > of modules, well, including only those modules that get needed, then it
> > would do the same job as the current init script, without duplicating
> > the effort needed to identify and locate modules twice. Remember that
> > discover is used in the debian-installer initrd, so why should it not
> > also work for us ?
> Why not use discover in mkinitrd instead? With this solution you can have
> both, a small initrd without bloat and automatic detection of moudules
> needed to boot the system.
Well, that is what i proposed, didn't i ?
You know discover better than me though, do you have any wisdom to share
about generaly using discover in such a kernel initrd ? Does it cause
problem for discover being launched two times (once in the initrd, and
the second time in the real system), and what size and dependency
penalties does discover bring with it ?
Also, would it be needed to create a minimal discover database, with
only the modules in the initrd, or is discover robust enough to handle
missing modules that are listed in the database ?
BTW, i have two discover problems : via-rhine, as needed on pegasos,
doesn't seem to be loaded, altough it is listed in discover 2's database
with the right pci ids. discover 1 worked fine on this. And second,
about the 8139 ethernet card, and the presence of two modules 8139cp and
8139too, the second is often preferable over the first, but the first
gets loaded first, thus messing up the ethernet card in the example i
have at hand.
Friendly,
Sven Luther
Reply to: