I am a little worried about how we are going to handle all the kernel
modules required for installing.
Where are all the ide, scsi and net drivers going to reisde ?
The user will need drivers to suit the fetch method on the actual boot
media, that way they can fetch other install or kernel modules for other
peices of hardware.
The fetcher could need drivers from either ide, scsi or net, there is no
way knowing in advance which one(s) they will need, and we cant fit them
all on one disk.
We could have different installer disks to split up the modules, but
thats not a good long term solution for us or the end user.
We cant handle all hardware from the one disk, but we can easily detect
all hardware from the one disk.
Im thinking that we should have an optional pre-install step, the
pre-install step should
1) Collect all information required to make a custom boot disk.
a) Primary fetch method
b) Modules required to enable step a)
c) Prefered language (?)
d) Primary ui (?)
2) From information gathered in step 1) build a single custom install
disk.
Step 1) would be just 1 standard disk, and would only be necessary on
some architectures, and when installing from space a limited media
(floppy), which is the vast majority of cases. This pre-installer would
build a config file that contains all the information needed for step 2.
Task 1(b) could be done automatically with a hardware detection module,
with the option for manual intervention if the installer was being
prepared for other hardware.
Step 2) This would be an automated step, it would have to be done in an
environment that has access to all the kernel and install modules, it
would build the installer disk(s). That would then be booted from to
start the traditional installer.
This pre-installer could be used to by us to build different flavours of
installer like we currently do(ide, udma66, scsi, net, etc) that would
be downloadable, but would also be usefull to the end user to
specifically suit their environment.
I think this pre-install method would be more managble for us, and would
be more versatile to the end user.
Glenn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
