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 [EMAIL PROTECTED] _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub