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

Re: [debian-installer] Some questions



On Fri, Jul 27, 2001 at 02:07:17PM +0200, Raphael Hertzog wrote:
> [ Using the flag to not disturb those who are only interested in
>   the old boot floppies ]
> 
> Hi,

Hello,

> 
> i've taken a quick look at the documentation available in the CVS of
> debian-installer. 
> 
>[snipped] 
> Another point is that the very beginning of the install process is not yet
> clear in my mind. I understand that the boot image would include one
> or several retrievers (and their dependencies) in order to let the system
> get other modules for continuing the install but since we also want
> autodetection of hardware, this will also have to fit in that boot image
> (at least to autodetect the medium that will be used to retrieve the rest
> of the install), no ? 

FWIW, since I have nothing to do officially with d-i, there are several
different steps that are involved in the bootstrapping procedure (BTW,
Debian's bootstrap will be a more acurate name).

When one thinks about the stuff, there is one and only one thing necessary
for the bootstrapping procedure: to be able rapidly to access non limited
resources [ in fact "non limited" means non limited to a few Mo ].

1) Bootloader
2) Bootstrapper [Note: in the future one can imagine that 1 and 2 are merged
                 into a BOS --- Boostrapping OS]
3) Production OS [with a user space installation process]

The key point is 2, since this is the point where we have a limited amount
of space (the original resources). What needs to be made in 2? NO
INTERACTION, NO GUI OR UI: to load the correct modules to be able to access
supplementary resources, and then pivot_root (with Linux) to that.

There should be strictly no size limitation for the GUI/UI since this has
nothing to do in 2. But for efficiency, there must be limitations on the
GUI ;)

How to achieve 2?

A multi choices installation can be made on El Torito CDROMs or, using for
example GRUB and a correctly configured ISD dhcp, via network.

Boot floppies installation can fit on one floppy if a choice is made (floppy
for network install, floppy for CD install, for ppp install and so on), or 
at least two floppies for a generic floppy install (will need drivers).

The keypoint in 2 is to be able to detect the correct class device to drive
in order to access the supplementary resources. The detection needs to deal
with two kinds of devices: PCI and ISA.

For PCI, I have written a script that parses the Linux kernel sources and
builts a database with Class Vendor Device Driver records [I will publish
the script on monday since I have still some work to do on it, at the moment
I have an almost 700 entries DB automatically generated... and found
problems]. 
There is still a bottleneck: clones, that are detect not by Vendor/Device ID, 
but by probing some SAPROM registers (example: ne2k-pci NIC). One can
imagine to improve the DB with the correct Vendor/Device/Driver, but this
will be suboptimal.

For ISA, what is really needed? ONLY the devices that may contain resources.
Are there CDROMS on ISA? I don't think so. The only thing I have in mind are
the ISA NIC.
-> Once we are able to access supplementary resources, we can use other
tools to detect the whole hardware.
-> Card sound detection, graphic card detection and so on are not a problem
for the BOS.

The following step (say 2.5) will precisely detect all the hardware and
install _a_ kernel (Linux or other) able to give access to all the material
resources.
The next step is defining the logical destination of the computer: here
comes (or not) the user interaction, and all is done with enough room (but
still one must think to be efficient, and not waste memory resources or
time; the smaller the better).

Cheers,
-- 
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org/



Reply to: