Re: [vague discussion] woody boot-floppies plans
Ive kinda butchered your email a bit, my comments about points 2, 4 and
5 can basically be answered by, is this a reboot-less install ?
<snip>
> New design
> ----------
>
> Here is an overview of the new design I am proposing. The install process is
> modularized, and works like this:
>
> 1. initial boot off of install media (floppy, cd)
> - Syslinux (or other loader for other arch) is run, and it boots the kernel
I think we should be aiming for grub as the standard bootloader on
bootflopies. Im not an expert on it, but from what i know.
a) it has the capability of being able to install itself to other media.
So it could be used as a (temperary?) bootloader for the hdd (if
needed).
b) This would be more usefull if using as a rescue disk as well. (if you
need to re-assert your hdd boot record).
c) Also it works on more architectures so it would be usefull in more
situations (im pretty sure im correct here)
> 2. kernel boot
> - the kernel sets up an initrd, which contains the installer,
> UI, and bootstrap loader, and runs the installer
I assume (from furthur down) this kernel is specifically built for
installation, not intended to be used as a general purpose kernel after
install. (hmm im confused about this point, see below)
> 3. installer
> - figures out what UI to use and starts it in the most portable mode that
> UI has (ie, uncolored text in English).
> - runs the UI's setup program.
> - probes to see if any extra modules are available on the initrd. If so,
> sets them up. (optional)
> - if more than one downloader is available, asks which to use.
> - runs the downloader's setup program.
> - asks the downloader to see if there are any extra modules it can
> download. If so, gets them and sets them up. (optional)
> - tells the downloader to download the partitioner.
> ***** note that everything from here on is not on the initial boot floppy *****
> - mounts the partitioner on a ram disk, and runs the
> partitioner's setup program.
> - tells the downloader to download the base system.
> - unpacks the base system onto the filesystem the partitioner set up.
> (In an ideal world, the base system would be smaller, just containing dpkg
> and it's dependancies, and the rest would be downloaded and installed
> as .deb's in a chroot.)
I think i agree with you here, i think the base system should be more
like a mini-distro, no bigger than a few MB, i.e. a kernel, bootloader,
busybox, shell (ash), editor (think ae or nano, NOT EMACS), apt-console,
dpkg, debconf, and anything else thats absolutly required to be able to
install from your choosen source media, such as net tools if installing
from the network.
I think the only use for base.tgz is if there are packages that are
absolutly required but need to be customised (from the official package)
to better suit the install. An X module may fit in this catogory, but it
would only be need if doing an X install, so i guess its a module
> - chroots into the base system and runs the base setup program.
> 4. base setup program
> - This program runs inside a complete debian base system.
> - Sets up some but probably not all of:
> - lilo (or other loader)
> - the initrd debian will boot from
> - the timezone
> - additional hardware
> - shadow passwords
> - root's password
> - another user account
> - networking
> - Then it reboots into the full debian system, or perhaps optionally
> just runs init to start it w/o reboot.
To be able to go to step 5, the only packages that need to be finalised
are the chosen kernel and bootloader, everything else can be installed
without rebooting via normall installation/upgrade methods.
> 5. booting the full debian system
> - Since the system was installed with a minimal kernel that cannot talk to
> the hard drive, an initrd must be used. The initrd has a syslinux file on
> it, and a set of modules. It just loads the modules, in a certian order,
> with certian parameters, and then lets the kernel pass control to init.
>
Im a bit lost here.
When you say booting, do you mean rebooting, or initrd passing control
to init?
If the kenrel you booted with from the beggining is the permenent
kernel, then would it be able to talk to the hdd all along ?
Do partitioning programs access hdd directly or with some kernel
support, can you partition an ide drive without ide support compiled
into the kernel ?
> The modules follow.
>
> The UI
>
> This is some kind of a modular UI with a simple API so other modules can use
> it. It's probably not much more complex than dialog. I want to say
> "mini debconf!" here, but I dunno if that's wise. :-)
>
> The UI has a basic setup program that is intended to ask just enough
> questions to get the UI setup and working. It might probe instead of asking
> questions. The things it needs to find out are probably:
>
> - what is your language?
> (This could be probed by looking to see if any other languages are
> available and if not, going with the one language that is)
> - If text GUI, does color work?
> (This could be assummed in some cases.)
> - If other GUI, other stuff.
> (Probing possible.)
>
What about an X based GUI option if the conditions suit ?
I have some ideas about how we could get lots of tempery available space
to support an X install, but im too sure if its technically possible (i
havent tried it), i primarily thought of it for the parittioning, but it
could work to provide space for an X install as well.
If your initial kernel has raid and loopback support it may be possible
to setup multiple loopback devices in a raid 1 (mirroring) mode.
If you need to repartition the area where one of the loopback devices
(and the partitioning program) resides then because the data is mirrored
on another loopback device it can be destroyed and reconstructed in its
new environment after that area of disk has been repartitioned.
Obviously one loopback device would have to exist to be able to rebuild
the mirror on the reconstructed loopback device (after the repartition
of that area).
If only one disks existed it could not be partitioned in one go, also to
create a single parition on one drive if thats all you have you would
have to resize the partition.
Actually talking about GUI's whabout basing it on GGI, this is pretty
generic, then we could install GGI for frame bufferdevice, is there
anywhere framebuffer device doesnt work ?
GGI, could provide a standard graphics environment for X or other types
of GUI's.
> The downloader
>
> The sole purpose of this component is to acquire a file from somewhere.
> It might accomplish this by loading it off of floppies, or off a cd,
> or by initializing the ethernet, running dhcp, and then tfpting,
> nfs loading, or ftp or httping it off a server. Or even by setting up
> a modem and ppp, and downloading it.
>
> It is intended to be a modular compnent, with a simple API. There are two
> API calls:
> - set yourself up (may be a no-op, may be quite involved)
> - download a specified file to a specified location
>
> This lets one (very simple) downloader be put on CD's. Other loaders might be
> put on floppies, one per floppy. So there will be a "piles of floppies
> install" floppy; an "ethernet install" floppy, a "ppp install" floppy, etc.
>
> The partitioner
>
> The sole goal of this component is to set up the install destination
> and the swap space. So it will have drivers for various disks, a disk
> partitioner(s), formatters, etc, and when it is run it will interact with the
> user (or probe) to set up the disk.
>
> One other thing this module does is it stores data about what modules
> loaded, and how, plus what device files it made, etc. This data is used
> later when the full system is booted via initrd.
>
I like the idea of running the partitioner from ramdisk, nice and
simple, i should have thought of that before i came up with my elaborate
plan with raid over loopback devices..
> Extra modules
>
> It should be possible to include extra modules on the boot media, or in the
> initrd (easier). These are almost like debian packages. They can be
> installed into the initrd, and provide extra functionality. When installed,
> a setup program in them is automatically run.
>
> The main thing I expect this will be used for is a module that provides a
> basic shell system and some tty's (busybox). I'm sure someone will want to
> stick doom in one so we can compete with Caldera's tetris. ;-)
>
> -----------------------------------------------------------------------------
>
> --
> see shy jo
Sounds pretty good so far, even though theres a bit im not sure about.
Glenn McGrath
Reply to: