Re: [mingp@COREL.CA: How we can with your Setup Engine?]
|> ** High Priority **
I don't know *how* I never got this message. It must have somehow
triggered one of my mail filter rules.
|> Wichert passed your name to me as a point of contact to see how
|> Corel can help you folks in the setup engine. If you can give us a
|> list of things/ideas that need to be done, we can then see which
|> area we can get involved in.
Excellent. If you don't mind, we should probably correspond by way of
the <email@example.com> mailing list. I am on that list,
also this way we can make sure that we don't lose a week because
someone (me) somehow (?) lost an email. This way, I can be the main
liase, but if for some reason I don't respond, someone else can pick
|> First, just let me tell you what are our goals. Our setup goals are
|> of course to have:
|> 1. a X based graphical install (we can leave this out of the
|> discussion for the time being as we are only concentrated on the
|> setup engine here)
Actually, we already have this, but rather than making it X based,
we're using the FrameBuffer devices from the 2.2 kernels. This
actually *can* fit on a 1440KB floppy.
|> 2. The setup is going to be broken into several
|> categories ranging from Easy to Fully Customizable. For the Easy
|> option, if the user has to hit any key other than <Enter> in
|> general, we would consider that a failure.
I like that. Maybe "Easy" and "Expert". Here we're talking about
dbootstrap, which is the program which is run to ask all the questions
for install, to install the OS, kernel, modules, and base system.
After all this is installed and the user then boots into his new
system and another little bit of setup is run (set root password,
create a user, etc) which we could call "Initial Tasks".
|> 3. Complete hardware
|> detection (video, network, sound, SCSI, ... etc.). We will start
|> off by supporting PCI devices and the few well known Plug&Play ISA
|> devices only. More hardware detection will be added as time goes
Now, we are talking about the ARM hardware right? Auto detection for
x86 is desirable -- complete detection is not possible.
I think, anyhow, that if we could formulate a simple system like the
* insert a module
* run a script which tests whether the module was "sucessful"
(i.e., the blogic card modules when successfully installed will
add new devices to /proc/BusLogic/<number>
* based on that, either leave the module loaded and mark the module
as to be loaded, or unload it
|> 4. The setup engine should have no restraints on whatever
|> front end tool the user chooses to use (e.g. GNOME based, Qt based,
|> or direct frame buffer based.)
Well, see above. I guess we need to step back a little... read below.
|> One of my engineers (Gary Ng, firstname.lastname@example.org) has already spent
|> the last three weeks dissecting the Red Hat install. He has a good
|> understanding on how certain things are done with their install
|> even though there was not a single line of comment in their source
|> code - maybe this is Red Hat's idea of open source. Hopefully, if
|> things go well, I should have another very experienced engineer
|> starting in a week or so - he has very good experience in low level
|> work and hardware detection.
Yes -- I don't really know that much about the RedHat system.
Our system is pretty easy to digest:
* initial boot from floppy, TFTP, CD-ROM, OS loader (i.e., loadlin)
* go into dbootstrap program -- this asks for baseline configuration
info, such as what modules to load, timezone, etc.
* install OS and modules (from floppy, cdrom, disk, network)
* install base system (from all the above and maybe more)
* boot into your new base system
* complete a few more installation tasks
* then you run dselect or gnome-apt or whatever
|> If you can get back to us on how to proceed further and quickly on
|> this, that would be great. We are targeting to show this new
|> install in the next Linux World (August 10-12, 1999). I guess an
|> explanation on how the existing Debian setup works would help too
|> in addition to the list of To-Do items. Lets work together to make
|> the Corel/Debian distribution the No. 1 Linux distribution in the
Sounds definately doable, and might mesh well with our potato release
You seem to be decided on a X11 system being used right from the top
(i.e., right from step 2 above). I don't know that we feel this is
necessarily the best idea -- I think we're thinking more along the
lines of the FB devices. Someone on the debian-boot list already has
code showing dbootstrap running in a FB.
The other reason why an X11 dbootstrap would be hard is that we
*assume* that the rescue disk and drivers disk are 1440KB. I think
it's a problem that the system isn't more flexible about the rescue
disk image size (i.e., possibly making CD or OS booting easier).
Anyhow, I guess you guys are basically tossing floppy installation?
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>