Re: redesigning the debian installer
I rather wish I'd seen the beginning of this thread so I could gain
some context. I'll see if I can find it at the archive so I can be
better educated, but for now I'll try to offer my comments as is.
I should introduce myself first. I am the operations team lead for
AuctionWatch.com (the .signature is for my side project; I have
interests in Debian besides those of my employer's, but they don't
Currently we're using Red Hat Linux because of its kickstart
installation process. I'm not terribly thrilled with Red Hat for many
other reasons, but I am quite fond of Debian. However, with Red Hat I
can install 100 search servers in under 15 minutes. Currently there
is no easy way to accomplish the same feat with Debian; it is my
intent to help offer advice and comments that hopefully will lead to
an unattended installation process for the next release of Debian.
On Tue, Sep 12, 2000 at 05:24:41PM -0700, Joey Hess wrote:
> > Which UI: Text, fb, X11 or all selectable ?
> Whatever UI is being used. (Not sure I understand the question.)
Serial console redirection needs to be available. We have hundreds of
servers (with Intel L440GX+ motherboards with serial BIOS support)
attached to Portmasters. These are headless boxes.
> > "It might also include language selection" ?? Not might, it is a must.
> I meant that it may or may not make sense to do this as part of UI
> configuration. It may turn out that it makes sense to do it as a
> seperate step if the code can be shared amoung all UI's.
This should be settable in the installation profile for an unattended
> > > - Reboot the system
> > We will avoid system reboot.
> We may provide an _option_ to skip the system reboot.
This sounds like a more reasonable option. In an unattended
installation it's best to stick in a floppy, watch it read for 90
seconds, eject and go. The system should be capable of being rebooted
immediately after installation into production mode (provided, of
course, that the installation and configuration profile was correct).
> > Another important point is an hardware detection database.
> This is left up to the modules that provide support for the various
> hardware. We need to pick a good hardware detection library for those
> modules to use, that's for sure. There are several. libdetect0 is
> already in Debian (but it's 155k! Urk!).
I think that hardware detection should be optional. In our case, we
have hundreds of servers, all the same hardware, and we know pretty
darned well what's in them and that's not going to change for awhile.
In the case of mass installation it's probably better that it just be
manually specified and not risk breakage due to a possibly incorrect
Michael S. Fischer <firstname.lastname@example.org>, AKA Otterley
Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA
Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323
PGP key fingerprint: 53BD 4179 C3C6 DF0F A8D6 10E6 E1D9 7091 D330 F08D
"From the bricks of shame is built the hope"--Alan Wilder
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org