Re: redesigning the debian installer
"Michael S. Fischer" wrote:
>
> On Wed, Sep 13, 2000 at 04:09:09PM -0400, Adam Di Carlo wrote:
>
> > I believe there must be a module subsystem defined for not just
> > retrieval issues, but also:
> >
> > - network/hardware support (discussed above)
> >
> > - network configuration (dhcp/bootp)
> >
> > - target media support (what we're installing to -- this means
> > PCMCIA/IDE devices, NFSRoot, RAID boot/root, etc.)
>
> I think someone recently brought up the idea on debian-boot of having
> an "installer builder," which seems like a wonderful idea. My idea
> would be to have a Web-based builder script on the Debian Web site
> (transportable, of course, to a local system if necessary) that would
> provide maximum flexibility. With such a scheme, one could create and
> download a boot disk (or set) that could contain the "kitchen sink",
> or, alternatively, a very slim 1.44MB boot disk or PXE boot set that
> could be used to perform a non-interactive installation with a known
> set of (perhaps customized) packages on a known set of hardware.
>
> I'm drooling already,
>
I think the biggest reason to have an "installer builder" is to allow
end users to simply use they own kernel rather than a generalised one, a
customised kernel can be ~500KB, whereas a generalised kernel trying to
make everyone happy will be aproaching 1M. If the user has there own
kernel-.deb built with make-kpkg then it could be possible to do this
painlessly.
Also the user building there own customised installer would logically
only include modules that apply to them, eg. they wouldnt include an NFS
modules if they dont intend to install from or too NFS, same with
detecting different types of hardware e.g. ISA, CDROM etc.
I think enabling heavy end-user customisation is the best chance we have
of buildign a 1 disk installer. I think it would be very challenging to
build a 1 disk installer for the masses if your kernel is 1MB leaving
400KB left to work with, 400KB would get most of busybox in, but not
much else.
Perhaps customising the installer could be a solution for a "hands-free"
or "non-interactive" install as well.
1. Build Customise Installer [OPTIONAL]
a. allow user to define what kernel and kenrel modules to use.
b. allow user to define what installer modules they require (at least
one) from each of the modules sub-layers fetch method, hardware
detection, target mdeia.
c. pre-configure the install method verbosness and defualt UI (i.e.
dpkg-reconfigure debconf).
d. set the default value for any question
2. Run installer.
Step 1 has been done by someone else, this closely resembles a regular
install method.
If someone wants a non-interactive install they can start at step 1 and
preconfigure it to default values (or methods) that are correct for
their situation, and then set it to non-interactive at this stage.
Step 1 is akin to building different flavours for an architecture, i.e.
i386 has udma, scsi, ide, compact flavours, the install team could just
prepare one version for each architecture and give the user greater
ability to build there own flavour.
But then we can also setup methods that autobuild customised installers
through web pages or other programs.
Glenn
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: