bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A question and some ideas


From: jbrock
Subject: A question and some ideas
Date: Mon, 2 Apr 2001 02:02:46 -0400 (EDT)

I just found about about GRUB through Usenet and I'm quite interested,
since I have felt for a while that such a thing was needed.  I hope
you won't mind if I ask a question.  (I've taken a quick look at
the manual at http://www.mcc.ac.uk/grub/grub_toc.html, but I haven't
had time to read the whole thing carefully, and in any case I'm
not sure the answer to my question would be there).  Also, I hope
you won't mind some suggestions.  When it occurred to me that an
open-source universal loader would be a good thing to have I started
thinking about what it should look like and be able to do.  It may
be that you will find some of my ideas useful.  Or it may be that
some of what I am looking for is already there in a form that wasn't
clear to me, in which case I hope someone will point this out.

My question has to do with Int13 Extensions.  Does GRUB use them?
I see many references to LBA, but I thought that was something
different.  I thought LBA was a scheme to remap tracks and cylinders
in a way that would allow the BIOS could see as much as 8GB using
the *old* Int13 interface.  I'm pretty sure my 6 year old 486 PC
supports LBA, since I upgraded to a 4.2GB disk and everything works
fine (without one of those Ontrack Disk Manager thingies).  I
thought Int13 Extensions was something different -- an entirely
new interface which would allow a BIOS to see a *much* larger disk
without any tricky remapping.  Am I completely confused or what?

Now for my suggestions.  I've been using OS/2 for a long time, and
when I started thinking about a universal loader the OS/2 Boot
Manager was my starting point.  But I quickly got more ambitious,
because it seemed that there were a number of functions that could
naturally be grouped together with the loader to create a larger
and more useful beast, which I am calling a Disk Manager (DM).
Here is the spec list I came up with:

        1) The DM should live on its own partition (which could be
        either a primary HD partition or a floppy).

        2) The DM should be completely independent of any operating
        system.  It should be a stand-alone mini-OS totally concerned
        with booting and disk management.

        3) All disk and display interaction should be take place
        through standard BIOS calls (Int13, Int13 Extensions if
        available, and VGA).  In particular this means no booting
        to another OS and using its disk or display drivers.

        4) The DM should have a full screen text based VGA UI (no
        mouse support, unless there is a way to do that which is
        guaranteed to work for all mice).  The UI will include a
        Help system and will display all available information
        about disks and partitions.

        5) The DM should know how to boot any OS.  If there is no
        direct way to guarantee this then it should be possible to
        upgrade it by dropping in modules with specific instructions
        for specific OSes.

        6) The DM should be able to create and remove partitions.
        (Note that this requires no knowledge of file systems).

        7) The DM should be able to move or copy partitions.  (I'm
        not sure whether it needs to know about file systems for
        this, in particular if it is copying a partition from one
        HD to another).  An extension to this might be the ability
        to compress and uncompress partitions, which would be useful
        for backups.  I'm not talking about compressing a partition
        in place, but rather creating a compressed copy and then
        recreating the original from that copy if necessary.
        (Again, I don't know if this requires file system knowledge).

        8) The DM should be able to resize partitions.  Clearly
        this does require knowledge of file systems, and as new
        file systems are created it should be possible to upgrade
        the DM by dropping in modules that know about them.

        9) The DM should be able to format partitions with any of
        the file systems it understands.  Optionally (and if it
        makes sense) it should be able to defragment those file
        systems.  In fact file system support should be done through
        modules which offer options appropriate to each individual
        file system supported.

        10) The DM should have a disk editor which would allow you
        to edit any part of the disk directly.  (Dangerous of
        course, but sometimes very useful).

        11) The DM should have a simple file editor which would
        allow you to edit files on those partitions containing a
        file system the DM understands.

        12) The DM should be able to create a copy of itself on a
        HD or floppy.

What motivated me is the thought that it would be *extremely* useful
to have a single open-source program that could live on a floppy
disk and would do *everything* necessary to prepare a PC for Linux
installation.  Let's say I buy a new PC with Windows 2000 pre-loaded.
I want to be able add and boot Linux (or maybe something else), I
want the process to be as simple as possible, and I don't want to
have to use non-open-source software.  So I take a floppy disk with
DM on it, boot to the floppy, bring up DM, use DM to shrink the
Win2000 partition, create partitions for Linux, create a primary
partition where DM will live in the future, copy DM to that partition,
and set it as active.  In one session I have done everything needed
to prepare the HD for a Linux install (and future multi-booting)!

The key point is that I think that booting and partition management
and filesystem management are a natural combination in that they
all involve things you want to do *before* you settle down to do
real work requiring a real OS.  In fact I think the first two (i.e.,
anything that does not require knowledge of filesystems) really
belong in the BIOS, and *would* be there if PCs had been thoughtfully
designed from the beginning!

A disk management suite like this, especially one that allows
plug-in modules for new file systems, probably can't be squeezed
into the tiny nooks and crannies where loaders like LILO and GRUB
normally live, and that's why I think a whole primary partition is
required, as with OS/2s Boot Manager.  It seems to me that you are
really jumping through hoops to squeeze everything down so much,
and that having a whole partition to work with would open things
up and simplify things dramatically.  You wouldn't even need to
tamper with the MBR; just set the DM partition active and it would
boot like any other stand-alone OS.  The only disadvantage is that
you lose one primary partition, and given that only Microsoft OSes
*require* primary partitions how many people who use GRUB are really
going to want to have *three* MS OSes on primary partitions in
addition to whatever they have on their logical partitions?  Also,
you wouldn't have to put in all this functionality at once.  You
could just start with a framework which could create and remove
partitions and boot from them (i.e., the bare bones) and then
gradually add other functionality (the way Linux itself grew!).

Of course, I'm very much a novice about all this, so it's quite
possible that some of what I am suggesting doesn't entirely make
sense, or alternatively perhaps there is already a way that GRUB
can be combined with other utilities to create the sort of system
I am suggesting.  Any thoughts or comments that any of you have
will be most welcome!

John Brock
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]