Re: Improved aboot (with updated documentation) from boot floppies

[David Huggins-Daines <dhuggins linuxcare com>]

"Greg Lindahl" <glindahl@hpti.com> writes:
> (and Rich Payne wrote - ed):
> > However, this makes more difficult for
> > the disributions right? At the moment if they see SRM they are safe to
> > setup BSD and go on, if they see MILO in the serial number string then
> > they need to use PC partitions.

Indeed, this is exactly what I am doing for the next Debian release.

> No. Distributions could just change nothing, or you could give them the
> ability to detect SRM capable of dealing with DOS partitions.

I'm pretty sure that SRM capable of dealing with DOS partition tables
(note that SRM has no concept of partitions - this is entirely up to
the secondary bootstrap) is never going to happen [1], because it
would break the Alpha architecture specification, specifically the
console subsystem specification, which SRM follows.  You might as well
ask, "why don't we have an AlphaBIOS that understands BSD disklabels",
or better yet, "why don't we ditch this stupid PC-BIOS on i386 and get
some real firmware, so we can partition our disks and boot however we
like". [2]

Anyway, I don't really want to use DOS partitions.  The only reason
Linux uses them on i386 is to interoperate with the "native" operating
system on that platform and the firmware that supports it (ditto with
Alphas that boot from ARC).  That's why we use Sun disklabels on Suns,
SGI disklabels on SGIs, Macintosh partition tables on Macs, and so on.

The only reason that DOS partitions are better is because of the
poor state of the existing tools for dealing with other partitioning
schemes.  On Alpha, we got used to using them since we had MILO and
Windows NT.  Now we don't have MILO or Windows NT anymore, and we'll
have to learn to be like the other non-Intel platforms.  In the end I
think this is a win.

It's in fact a lot *easier* to write an fdisk-type program for OSF,
Sun, or SGI disklabels, or for Macintosh partition tables, than it is
to write one for DOS partition tables, because you don't have to deal
with the extended/logical partition madness, or with the antiquated
CHS specifications for size and placement of partitions, or arbitrary
PC-BIOS limitations on these (wholly artificial) numbers you have to
abide by in order to be backwards-compatible with 16-bit toy operating
systems and the broken firmware they rely on.

BSD on i386 really has the worst of both worlds, since it has to put a
BSD disklabel *inside* a DOS partition in order to be bootable from
the PC-BIOS, and the problems with Linux fdisk's BSD label support on
Alpha are somewhat related to this. [3]

> I agree. However, there are usually technical ways to get around most
> installation difficulties. And the gain from being able to use DOS
> partitions will be substantial.

No, the gain from fixing the partitioning tools to work better with
the different partition formats on the various platforms will be
substantial.  It will also have benefits for all architectures, not
just Alpha. [4]

[1] David Woodhouse pointed out to me that you can, with some twisted
    hackery, create a valid DOS partition table and still boot from
    SRM; it involves twiddling the empty spaces (er, "Reserved to
    Digital" spaces :) in the boot block so that the most significant
    halfword of the bootblock checksum is 0xAA55 - also you can't use
    the fourth primary partition since it overlaps with the rest of
    the checksum.  (Hm, in fact, since the 0xAA55 magic number isn't
    really required to boot on an Alpha (no PC-BIOS), so long as Linux
    understood that it was optional on Alpha, we could actually do
    this - but I don't want to give anyone any ideas :)

[2] Actually, people have done that in the past (SGI Visual
    Workstations, which are i386 boxen that use ARC), and are now
    doing it *right* (VA Research's "ROMulus" project, and LANL's
    "LinuxBIOS" project)

[3] IMHO we should treat OSF disklabels as a separate type, like we do
    for Sun, SGI, and AIX labels, but this is kind of irrelevant
    because Linux fdisk really needs to be put out of its misery at
    this point.

[4] In fact, I'm working on something like this, namely, a universal
    disk-partitioning library and accompanying utility, in my Copious
    Free Time, probably by filling out the (read-only, but
    multiplatform) libfdisk that resides in Debian boot-floppies.

-- 
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 tel
dhuggins@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.