Re: redesigning the debian installer
Michael S. Fischer wrote:
> 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.
The context you're missing is that we're going to rewrite debian's
installer for the next release of debian. My initial manefesto for this
can still be found here:
http://cvs.debian.org/debian-installer/doc/design.txt?rev=1.1&content-type=text/vnd.viewcvs-markup
Although several of the details have changed.
> 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.
Unattended installs are something I am interested in as well. They're an
important part of the new design.
> > 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.
Sure -- Debian has always supported installing from a serial console,
and I hope it always will.
More generally, I expect that the new debian installer will need to
support all the features and everything that the current installer
supports. Of course the initial prototypes won't, but it will not be
suitable as a replacement for the current installer until it does
support everything.
> 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
> detection mechanism.
Unless someone knows of a case where PCI hardware detection can fail, I
don't see a problem with doing it. But any invasive hardware detection
is going to require a way to let the user choose to manually specify the
hardware instead of having it detected (read on).
> I think it is vitally important that the postinst will be able to
> accept some sort of file in lieu of interactive input so that the
> package will be able to be configured non-interactively.
>
> DHCP can assist the installer with determining the location of such
> information.
The plan for the new installer is the use debconf (or rather, a similar
but smaller implementation of the same ptotocol) for all (or almost all)
user interaction.
The nice thing about debconf is that it reduces all user interaction to
a series of questions. It keeps track of the answers to questions, and
that data can be fed into a later install in various ways. When that's
done, you effectively get a kickstart system for mass installations.
Relating this back to hardware detection, for example, you do one
install manually. If you elect not to do hardware detection and instead
specify hardware, debconf remembers that and remembers each of your
answers. Then when you're doing a mess install, those same answers are
fed into the installer.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: