Re: Step 1 of debian-installer
On Tue, Feb 20, 2001 at 09:43:29PM +1100, Glenn McGrath wrote:
> Thierry Laronde wrote:
> >
> > - Size of a floppy is the critic point. You can have more space on a HDD,
> > by playing with the number of sectors. But you need to have a bootloader
> > able to identify the CHS parameter in order to access and load the data
> > (kernel and root fs); for x86, Lilo can do that, and there is a patch to
> > GRUB to allow this too;
> >
> Do you mean you can have more space on a floppy ?
> e.g. 1743KB, 1840KB, or 1920.
>
> I think that formats that use multiple sector sizes cant be booted.
The problem is that you need a bootloader able to retrieve the correct CHS
parameters for the floppy. To summarize the situation (there are some
informations in the info files of `fdutils'), since the use of several media
types of floppies (720 Ko, 1.44 Mo, 2.88 Mo etc...), the BIOSes are no more
limited by a "hardcoded" value of the CHS parameters, there are able to work
with any values (supported by the controller). The problem is that a table
lists 8 types of CHS parameters, and that the extra-densities are not listed
in this table, so the "automatic" detection fails.
But if you have a bootloader able to take the CHS (for example put in the
BPP), you can access these sectors. But this is bootloader dependant, and
that's why the piggypack format of Linux, for example, doesn't handle this
case. You do need a bootloader.
The maximum conservative size of something bootable (via Lilo or a patched
GRUB) IIRC is 1840 Kb (you increase only number of sectors; increasing
number of tracks is more dangerous).
>
> > - The bootloader has a size; if one can use the bootloader installed on the
> > floppy as the data to install as the bootloader for the hard disk, the
> > same data is used twice, then there is no need to duplicate the bootloader
> > in the initrd; for x86, GRUB can be handled this way;
> >
> Yea grub is nice, i wish it wasnt so big though, i guess thats the price
> to pay for lots of features and being generally more usefull
Indeed, to reduce the size of the "core" GRUB is on the todo list of the
developers. So I think that in the future GRUB will be even _more_ desirable
to address the problems. But it is already usable I think, and we can
decrease the size at compile by defines in order to get read of some
builtins that are not really useful in this case.
To see an example of the use of an extended format, take a look at `tomsrbt'
home page (there is a debian package, BTW).
Cheers,
--
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org
PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org
Reply to: