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

Re: One or two floppies (was: first weekly debian-installer status report)

Vaidhyanathan Mayilrangam wrote:
> On Wed, Nov 01, 2000 at 10:30:33PM -0800, Joey Hess wrote:
> > Vaidhyanathan Mayilrangam wrote:
> > > >   - kernel module udebs [UNCLAIMED]
> > > >           Not started. We will need various sets of kernel modules;
> > > >           one such set is NIC drivers. Each set goes in a udeb; there
> > > >           probably has to be a system to build the whole kernel and
> > > >           udebs.
> > > I already did some stuff on this and got the different modules built. So if I
> > > can get the mechanism to build udebs, I can upload them and
> > > YEAH.. I claim this :)
> >
> > What are your thought on how this should integrate with our normal
> > kernel deb building procedure and all that? (If at all?)
> Just some prior info:
> The base kernel takes 385K and all the net drivers take 575K. It essentialy
> means it is a two floppy install (unless there is someway a user could choose
> only the drivers he/she needs). It is a catch-22 here.. We need to know the
> NIC card to choose the driver, but we need the module before that..
> Couple of ideas:
> 1. create a kernel with Tulip, 3Com, NE2K, Intel EtherExpressPro drivers built
> in and let the user choose this as a default.. (This will make it one floppy
> install for some, but the user should be aware of what NIC he has)
> 2. Have some way of telling the users the files they need to download and
> assume they downloaded the right files (Yuck.. I hate this myself)
> 3. Create a mutliple boot floppies for different combo (Nuff Said)
> 4. Can we fit in a code to detect NIC and activate it in about 400K.. If so,
> we can have one floppy with kernel and the net drivers and 400K code which will
> activate the NIC and start downloading everything ??
> Any more ideas ??
> Regards,
> Vaidhy

We need to be able to detect kernel modules required only for the chosen
fetch method.

I think hardware detection should have a higher priority than even
kernel modules for the boot disk, that way if the required modules arent
found then at least they are known, and the user can use a method such
as apt-zip to fetch the required kernel modules, then they can continue

If the individual kernel modules can be isolated then its much easier to
deal with them.

If the required kernel modules are know then it should be easy to make
custom boot disks with just the required kernel modules.

We also need to consider users that want to roll there own kernel.


Reply to: