The REAL Multi-boot

[A SEQUENTIAL READ IS SUGGESTED BUT HERE IS THE INDEX ANYWAY]
Have you ever desired to have multiple OSes installed in your computer?
Why multi-booting?
Requisites: [updated for version 2.42+]
Let's start!
A multiboot partition table
Installing the Ranish Partition Manager
The return of paper
An example of changing OS
The key thing you need to understand is this
Experiences: sparse hints to help you making the partition table
Creating a new partition
Planning the partition table
An OS as a rescue disk
Installing Operating Systems
Modifying the partition table: moving and resizing
Questions and answers
Comparisons to other techniques
Comparisons to other programs: LILO, BOOTSTAR and BOOTIT
[Update] Improvements with version 2.42+
 

Have you ever desired to have multiple OSes installed in your computer?
This page should be the answer for you.

There surprisingly seems to exist only one way in the world to do a flexible multi-boot.
The following tutorial will show you the way to do it for free. ( ! )

Don't stop reading saying "I know this, I can do it with LILO or any other of the 100 other boot managers around!". No, this is a completely different thing, you will discover it reading.

Why multi-booting?
Multi-booting allows you to have like many computers where you previously had one. It allows you to take benefit from the advantages of each different OS and the disadvantages of none.

In case you are a software developer or beta tester you will get the greatest benefit from this page because you will be able to test your program in many conditions, under many OS or even the same but differently configured. Yes, you have understood well: You can even install the same OS multiple times. Limitations? NONE: Only your HD space.

You could have Win98 for games, NT4 to work, Win2000 to evaluate it's stability and take the advantages of USB and Firewire, Linux to hack remote systems and use the powerful command files, and every other OS you desire, simultaneously on your machine (one running at a time). You could even have an entire OS dedicated to be the "rescue disk" for all the others, much more comfortable than an 1.44 MB floppy with DOS!

You will be able to have an UNLIMITED number of OSes on your HD with this method, and each one will be 100% independent from the others.
- Do you need to reinstall Win98 because it crashes too much? You can do it without any influence on the others.
- You don't like an OS anymore and you want to wipe its partition away to enlarge the others? You can do it safely.
- You want to resize anything? You just do it.

Requisites:
All you need is a large HD (it must contain all the OSes you need) and Ranish Partition Manager. The Ranish Partition Manager web site is at www.ranish.com/part. Go there and download the latest version.
 
 

 
 
Ranish Partition Manager is far the best partitioner all over the world, even if little known. You can use it for this purpose too. Kill those old FIPS and FDISK which are really obsolete if compared to RPM. BTW don't be worried by the "Beta" flag: RPM is rock stable and absolutely reliable... it's just that it has joined the "forever beta" policy.

The version 2.38 Beta doesn't still implement some features of the boot manager which were present in the old 2.37 final version, and for this reason was called beta, but allows HD>8Gb, has some good new features and a better user interface. We are not using the useless nonimplemented features so the only version you will need is the last 2.38 beta alone. For curious people the still not implemented features are the boot manager options "previous", "next", "last" and "last3". They allow a multi-boot with more than 4 primary partitions, but just in a very limited way. We are going to do much better than this with the 2.38.

To understand the following part you probably need to learn everything about partitions and the Ranish Partition Manager. All the things are very well documented in the www pages at the author's website. Read everything.
Note: much of the documentation refers to version 2.37, so things will be a little different in 2.38.
The version 2.38 comes with a help text file, read it carefully.

The Ranish Partition Manager is almost freeware (10$ but with an evaluation period of 10 years). It's incredible that such an excellent software is given away for free! Cost is really not proportional to quality of software...

Let's start!
I started with the idea of writing brief instructions for Ranish Partition Manager experienced users, but I ended with a very long tutorial on partitioning and multibooting. I'm sorry, it will take some time for you to read it all but it's full of useful information and experiences.

I have tried to put things ordered from the most general information to the most detailed one, so that an experienced RPM user can stop reading as soon as he/she understoods the guidelines.
For unexperienced users it's a very good idea to read it all because contains more than one year of gathered experiences.

A Multiboot Partition Table:
And so how can you do this complete multiboot? Here it is:

Let's say you have a 18Gb drive and you want to set partition configuration like this (this is my current configuration in facts):
 

Note1:All these partitions are PRIMARY partitions!!!! This is very important!! Please use only primary partitions because they are the only ones which are truly independent one to the other and are bootable. You will not be able to have more than 4 simultaneously present in MBR but believe me: you will never need to have more than 4.

Note2: I have written here only the starting/ending "cylinders". And what about the starting/ending heads and sectors? The starting "head - sector" of every partition MUST always be "0 - 1" and the ending "head - sector" MUST always be "254 - 63". This is very important because partitions can only be moved or resized if their parameters are set like this. The only exception in the example is the partition for RPM itself: it can end or begin anywhere because you will never need resize or move it. In facts there are no valuable data there and you can at any time delete it and recreate it in a different position without losing anything.

So how can you put this partition table on your HD?

Installing the Ranish Partition Manager
Make a dos bootable diskette with RPM 2.38 Beta 1.x, and boot the system with it.

Start RPM and install the Boot Manager on the HD.
Now, about this: You have seen on the documentation that there are 3 different types of boot manager: Text, Compact and GUI. You will need the "TEXT 25x80" one.
GUI is like text but much heavier, and has no added benefits, only disadvantages I would say.
The Compact boot manager on the contrary is not suitable for our needs. It's like the LILO boot manager, you can see below the comparison "RPM vs LILO" (and when I say RPM there, I mean TEXT Boot Manager)

When you install the text version it will be asked to you to create a partition for the Partition Manager. That partition can be extremely small, as you see mine is just 1.4 megabytes large. You can use the last rest of cylinders at the end of your HD. In facts HDs often don't end exactly with head 254 sector 63 but usuallly with a different head: in my case 144.

--------------
ATTENTION! Version 2.42 update: Muthu says in the readme that it's not a good idea to use the last incomplete cylinder for the boot manager partition as I suggested, because... "linux does not like it. I could not get linux installation create its partitions properly. So my suggestion is to use the last COMPLETE cylinder for the RPM partition". So if you plan to install Linux, use the last complete cylinder for the boot manager partition, and leave the last incomplete cylinder UNUSED. Thanks Muthu for telling.
--------------

You should NEVER make normal partitions begin in "head - sector" different than "0 - 1" or end in "head - sector" different than "254 - 63". [Why? See below] So the last noncomplete cylinder is almost disposable and can be used for this job: you can use it to put RPM partition there. If you don't have a useless fraction of cylinder at the end to do the job, then use the last complete cylinder. If the last cylinder is occupied already, you could shrink your last partition. You will need just one cylinder.

You could even put RPM into the unused disk space at the beginning: from 0-1-1 (CHS) to 0-254-63, since that is another wasted area, but I'm not sure if I would recommend it because some OSes could be disappointed by the fact that exists a partition "before" the C:\ in the HD positioning. (The RPM partition must always be present in MBR and so it's always seen by OSes even if usually ignored). Anyway, if you do this, please force MBR positioning for the RPM partition as 4, it should work.

Now you have installed the TEXT boot manager and created a partition for the Ranish Partition Manager. And now?
You will notice that when you boot your computer, now the Ranish Boot Manager window will appear on top of the screen for 6 seconds. When that one is present you can press the "0" key and go into the partition manager instantaneously. From there you can modify your partitions in the HD. Whan you have finished doing this you can press F2 (=save to MBR) ESC (exit RPM and go back to the boot manager rectangle) ENTER (choose the highlighted partition and boot it immediately without waiting 6 seconds).

The return of paper
So we have discovered that now at boot you have way to change the partition table "on the fly" and boot with the new partition configuration.
And now can you see how near we are to the solution?

That partition table written above, mustn't be written alltogether into the partition manager since RPM 2.38 Beta will refuse to create more than 4 primary partititons. On the contrary has to be written on a piece of paper! (Don't lose it afterwards)
This is the very simple but very effective workaround to make the most flexible multiboot ever.

You can think it's too bad to write the partition table on the paper, but in facts it's not. At the end you will in facts only need to change 2 numbers on the screen when you change OS (see below), so it will take you less than 10 seconds and just when you need to change OS. A very acceptable time.

An example of changing OS:
Let's say I'm using WinNT4, so my MBR is:

* 171-370 06:Fat16 (Partition #4: NT4 System) [Active]
* 1024-2192 0C:Fat32 LBA (Partition #8: Common partition with the data for every OS)
* [nothing in the third place: use force 4th placement on the next partition, see RPM documentation on how to do this]
* 2193-End (End=2193,144,63) 0XF0:RPMPartition (Partition #9: Partition for the Ranish Partition Manager: must be always present)

Now I want to switch to Win98 primary installation. The MBR I need for that OS is:
* 91-170 06:Fat16 (Partition #3: Win98 System) [Active]
* 1024-2192 0C:Fa32 LBA (Partition #8: Common partition with the data for every OS)
* [nothing in the third place]
* 2193-End (End=2193,144,63) 0XF0:RPMPartition (Partition #9: Partition for RPM always present)

Do you see any similarity? Yes! The only partition which changes is in facts the first one. So what do I need to do? At computer startup press 0, go into the RPM, and change the first partition. The standard way would be: go on the NT4 partition entry, press DEL so you delete it from MBR, then press INS so you add a partition to MBR, type the correct cylinders - head - sector and the correct filesystem type. Press B so you activate it [->boot from there], then save and exit. You will return to the Boot Manager rectangle, which now is updated. Press [ENTER] to boot the default partition (the one you have activated).

In facts a much faster way exists: go to the number 171 and change it to 91, then go to 370 and change it to 170. Then F2, ESC, ENTER. You are immediately booting the other OS! Time needed to change OS? 10 seconds? Noo, Much less.
A few more seconds if you need to change the filesystem type too (you do it by pressing INS on the existing entry) but always less than 10 seconds.
These 10 seconds at OS change are all the disadvantages of this most-flexible-ever multiboot technique. Do you think it's much for what it gives to you?

The key thing you need to understand is this:
The MBR (Master Boot Record) stores numbers which indicate the placements of the partitions in the HD.

When you delete partitions using DEL on RPM, you don't in facts delete the partition from the disk but only the information about its placement in the HD. If you know the placement because you have written it on the paper, then you can at any time recreate the MBR entry and the computer will read the partition as before, flawlessely.
This is very safe, trust me.

Remember: every cylinder range that is not included in the partitions written in MBR is considered unpartitioned space full of random bytes by all the operating systems and partitioning programs (e.g. The Partition Resizer below). Everyone will ignore it completely, and this is the way with which we hide the other partitions to the currently running operating system: deleting their entries from the MBR and making them appear as unpartitioned space.

When you recreate the MBR entry you are telling the operating system "Hey, did you know? There is a FATxx partition in this position!" and if it's true the OS will read it. If it's false the OS will consider it unformatted.

If you make mistakes on the placement of the partitions when you modify numbers, then the line becomes red in RPM telling you there is something wrong. So it's very unlikely that you make mistakes.

Experiences: sparse hints to help you making the partition table
Before continuing, there are some things you may need to know:

* AFAIR Operating systems can only boot from a partition which starts below 8GB. So you will need to put all the bootable OS partitions as first items in the table. Data partitions should be set in higher cylinders. This is an hardware limitation, and it's not specific to a particular OS, so affects all. --- UPDATE: Not very true: I was mistaken. It depends upon how new is your bios and upon the operating system. NT4 can't boot from above 4GB (KB197295) and for above 2G you probably need Ranish's patch (see Ranish's FAQ). MSDOS also needs Ranish's patch to boot from above 2G, but after patching I don't know the limit. For Windows9x/Me I guess there must be some sort of limitations but where exactly? Try to stay low. For Windows2000/XP/+ and Linux I'm not aware of any limitations. If you have further info, tell me.

* What's the use of a common data partition? Well, firstly you store data there. Data should be visible to every OS because you are likely to use them from every OS. Secondly, I install there most of the programs! You have understood well, I call it data partition for short, but in facts I put there everything which can be shared. Program installations CAN be shared in most cases. You boot with NT and install the program X in D:\programs\X directory. Then you boot with Win98 and you install the same program X in the same D:\programs\X directory. You will have two installations, but just one set of files. This will work with 90% of the software. There are a 10% of programs which will stop working in the first OS after this, or which refuse to install again in the second OS. Nothing to worry about, you just (re)install them elsewhere from one of the two OSes. That 10% is made by hardware-related programs (drivers) or by softwares which deeply integrate into the OS like Internet Explorer version 4 and above.

* A big common data partition should be Fat32 of course: big size, top compatibility, top speed, low byte waste. It can be seen from every OS (Linux included) except NT4. To see it from NT4 you will need the System Internals Fat32 driver for NT4. This is the expensive part of the multi-boot. If you can't afford the driver so make it Fat16 or you will not be able to see it from a NT4 OS.
There should be a way to make a Fat16 partition bigger than 2GB (cluster size >= 64K ) you can try and see if it's possible by tweaking into RPM partition settings or using The Partition Resizer (see this). If you are able to do it tell me the way and I will write it here.
The common partition should not be compressed with Drivespace or similar programs since non-Win9x systems will not be able to see it. There is no workaround for this.

* Use Fat16 for NT4: The NT4 system partition should better be a Fat16 IMHO, because if you use NTFS you will not be able to access it with other OSes (see "An OS as a rescue disk"). NTFS partitions can be accessed only with NT4 and Win2000, but in facts exists another (shareware) System Internals driver to access it via DOS and probably win9x. Nothing exists for Linux AFAIK. I like Fat16 partitions more than NTFS ones also because they are faster to access and less noisy in HD movements (NT is using the HD all the time!). If you have a protected multiuser system you anyway need NTFS. Fat partitions can also be resized easily.
You cannot use Fat32 filesystem for the NT4 system partition because the System Internals driver doesn't work during boot.
I would on the contrary suggest Fat32 for the Win2000 system partition since Win2000 supports it...

* Minimum partitions size:
You will need around 300Mb to install Win98.
Around 250 Mb to install Win95 or NT4.
Around 950 Mb to install Win2000.
[I cannot tell for sure for the other OSes since I'm not an expert of LINUX, BeOs...]
Win95 and 98 can use Drivespace after the installation to effectively double their OS partition size. Very good, but only if you have a Win9x OS as 'rescue disk' [see below] otherwise you will not be able to access those partitions after compression.

Creating a new partition:
"The question comes spontaneously" (as we say in Italy). So how can I create a new partition with this nonstandard way of using RPM?
You "create" a partition by writing it on the paper and pretending it exists. [I'm not joking!]
When you "create" a new partition it will be not formatted. If it's a Fat partition you can format it using RPM directly: put it in the current MBR table on RPM and press the [F] key. If it's not Fat put it into the MBR anyway (so that it's visible even if unformatted) and use the proper operating system to format it.

Planning the partition table
Before beginning to install OSes you need to plan a good partition table on the paper, as the one I have shown above. Remembering that all the bootable partitions must start below 8GB, so you should put all the bootable partitions (the various OSes system partitions) before and all the data partition after. Help yourself with the short hints I have written in the "Experiences" paragraph above and plan starting/ending cylinders for all your partitions.

In order to associate the desired size to the Cylinder range you can use RPM. Use [+] and [-] keys on the ending Cyl and watch the partition size. Remember that nothing will be saved until you press F2 and even if you do, data on the disk will never be changed until you seriously do something like formatting the partition. Changing the MBR leaves the bytes on the HD intact.

You need to plan the MBR images too. What is an MBR image? The thing you save by pressing [F2] :-).
When you plan to install a new OS you need to decide how many partitions it will usually see. In my case the two OSes of the example were built to see at least their partition and the common partition (the partition for RPM itself is ignored by the OSes even if present in MBR). I have set the system partition in the first placement, so that it becomes the C:\ drive, and Common partition in the second MBR placement so that it becomes the D:\ drive. If I want at any time to make visible another partition to that OS I can put it in MBR#3 [3rd place in MBR] and it will become the E:\ drive.

If I have I installed programs for (= from) that OS in the shared "Common" partition, then it's very important that the Common partition is present at each startup of that OS. If you remove it from MBR, or change its MBR placement putting another partition before it, the drive letter would change and all your links to programs or data to D:\somedir\somefile would ALL be dangling!! The OS is likely not to boot properly.

For this reason what have I done? All my installed OSes have the Common partition in MBR#2 [and I put their system partition in MBR#1 so the OS is installed in the standard C: partition]. So I never make mistakes. I force the placement number 2 for the Common partition (hit button [2] in the proper column in RPM) and I almost never touch that line. The OS system partition is forced in MBR#1 and I only change the starting/ending Cylinder numbers (and sometimes the Filesystem type) when I change OS, so the "active" flag and the "force MBR#1" flag always stay there.

An OS as a rescue disk:
The partition at 1-50 (Win98 secondary istallation) in my partition table is a rescue OS. I use it as a rescue disk for all the other Windows operating system which have problems. Like this I can access the other OSes partitions from the outside and add/replace files and the like to fix it.
My rescue_partition is small, and all the software I have installed in that OS (only few programs) are installed in the system partition. So this (and Linux too) is the only OS for which I don't need the Common partition to be present when I boot.
This is important because I have the MBR#2 and MBR#3 both available for other partitions. In this way I can even copy one partition to another using Windows programs. For this purpose I would suggest you Powercopy2.x because it has been made for this purpose and it's extremely fast. You can download it from my homepage. It has some problems in copying files which are opened, so if you use it to copy full partitions it's a good idea not to boot from the source or destination partitions -> use the rescue OS.

Why have I chosen Win9x as the rescue OS?
- It's easy to install
- It fits in a small partition because you can compress it with drivespace afterwards and then you have some hundreds of new megabytes to install software on the system partition.
- It can read Drivespace compressed partitions of other OSes. Since I always use Drivespace compression for system partitions of Win9x OSes I needed a Drivespace-enabled rescue-OS.
x It doesn't read NTFS by itself... for this reason I have used NTFS nowhere.

So another good thing you can do could be writing some notes on the various OSes requirements on the paper: Do they require some specific partitions to be present together with them in the MBR? In which placement?

Installing Operating Systems
After you have fully planned and written your partition table on the paper and you have thought a bit at the MBR image for each OS, you can begin installing your OSes. How do you effectively install one?
The following is a good way for all Windows operating systems:

Reboot your computer and enter into the RPM. Put in the MBR only the system partition of the OS you intend to install (whether the RPM partition is present or not in this case it's OK anyway). If it's not formatted it's even better. Save the MBR image. Insert the installation CD of your new OS and RESET the computer so that it boots from CD.

The OS will scan everything (= nothing) and then asks you where you intend to install it. The NT-like operating systems will ask you if you want to install them in that unformatted partition or in the unpartitioned outer space. DON'T install them in the unpartitioned space because you will overwrite your other partitions! The OS will not see them but you KNOW that they are present!! Tell the OS to install itself in the partition you have created for it. The OS will format the partition if needed and then install itself there.

The OS will create the Boot Sector in its partition so that it becomes bootable as it needs to be.

The OS will overwrite the IPL in the hard disk which means that you will not see Ranish Boot Manager at computer startup anymore. Don't worry: just take the RPM diskette and reinstall it, Text mode, same cylinders for its partition as it was before.

Now that the OS is fully installed, for the next boots you can add in the MBR all the partitions you want, like a Common partition and so on.

I have had some problems with Linux with this installation method: it seems it cannot see partitions added to MBR after installation. To install Linux you will probably need to set the full MBR image before the beginning of the installation, and not only its two partitions. (The Linux OS partition and the Swap partition: Linux needs two. I suggest you to always put the Common partition in MBR#2 for consistency and so the Swap partition will go in MBR#3). UPDATE: Linux people have then told me that I only needed to *mount* the additional partitions which were added after the Linux installation. I hope it works. I don't know I have not tried to install it again since I don't really need Linux at the moment.

Modifying the partition table: moving and resizing
The best thing would be of course if you guess the perfect partition table at the beginning, but you cannot foresee the future and so there can come a time in which you need to shrink/delete a partition in order to enlarge another one.

If you want to delete a partition the method is easy: use the rubber and delete it from your partition table on the paper!
If you want to shrink, move or enlarge a partition I can suggest you another excellent program: The Partition Resizer (really Freeware this time!!) It can properly move & resize Fat 12, 16, 32 partitions and at least move all the others. The program is really excellent and extremely safe. It can even recover from a power-failure during a resize or move!

So please don't brutally cut the partitions as suggested in the RPM documentation but use The Partition Resizer instead. Like this you will not have the side effect of the wrong size shown by Windows. RPM documentation says that a Scandisk is enough to make Windows understand the new size, but I heard of many people for which this was not enough. So please really use The Partition Resizer.

Note1: Partitions which don't begin at (Head,sector) = (0,1) or don't end at (Head,sector) = (254,63) are NOT resizable nor movable! So this is a very strong point for which you should always use those standard settings when you make a partition.

Note2: The program correctly resizes partitions but it's not able to change the partition cluster size in the same reversible way. So you have some range for resizing but you will not be able to enlarge the partitions above the limit imposed by the current cluster size. E.g. a Fat 16 partition with a 16K cluster size cannot grow to more than 1GB. So when you create the partitions give a look to the maximum limit you are imposing them with the current cluster size. If you want to create a partition with the same size but larger clusters: create it with the default cluster size and then modify the cluster size using The Partition Resizer. Warning: content will be destroyed so do this before inserting data in it.

Mantaining content while modifying the cluster size is indeed possible but will require a dreadful work: You will need to shrink the partition P as much as you can, then create a small partition Q near to it with the desired cluster size, then progressively move all the files from P to Q. Shrink P at each step and enlarge Q. At the end kill P and occupy all the desired space with Q.

On the contrary there is no minimum size when shrinking a partition. [Of couse you cannot make it littler than its total occupied space!] If you see you are not able to shrink a partition as desired, it's because there are files which occupy clusters at the end. You will need to defrag it before trying again. If you see that some clusters stay at the end and don't move while there is free space before, they are probably damaged files which Scandisk cannot detect but Defrag cannot move. It happened to me! You will need to find a more powerful disk-scanner or a more powerful defragger. As last resort you can write to me, there is another way to do it.

When you resize or move a partition seems a very good idea to me to put in MBR the neighbouring partitions too: the one before and the one after it. So you will see them in The Partition Resizer and the program will not allow you to erroneously overwrite one of them with the resizing one.

The Partition Resizer works with LBA values for partition placements while you are using CHS values in your partition table on the paper. So you will need to use RPM to convert the values CHS<->LBA. Write down the new desired LBA values for the partition before starting The Partition Resizer.
 

Questions and answers
Q: What's the use of the Text boot manager?
A: No use. it's only there to allow me pressing "0" to access the Partition Manager.

Q: I absolutely need to have 4 custom partitions simultaneously present in MBR to do a very special thing. How can I do with the RPM partition? It occupies one MBR placement!
A: Delete its MBR entry (= uninstall Ranish Boot Manager) so you can use all the MBR to put 4 custom partitions simultaneously. When you have finished reinstall RPM Text Boot Manager in the same place using the RPM bootable diskette. Until you have your paper partition table nothing is ever lost.

Comparisons to other techniques
Some people posted into Ranish Partition Manager mailing list another way to do a multi-boot using the old version 2.37 and the new 2.38 Beta 1.x together. In facts there is way to use functionality of both, allowing the multiboot made by 2.37 (first, next, last, last3 choices, you know) and the partition table above 8GB to be made by the new 2.38.

Personally I wouldn't recommend this for some reasons:

1) You will not be able to put more than 4 partitions on the upper zone (above 8GB). Not good for big drives.
2) Changing the partition table above 8GB is very complicated.
3) You have all the limitations of the boot manager of version 2.37: for every bootable partition you will have way to make only ONE ( 1 ) MBR-image (one partition configuration) and only with the famous "previous", "next", "last" and "last3" choices, which are very limitative IMHO. See documentation for 2.37 to understand what do those options mean.
4) In few words: MUCH LESS FLEXIBLE.

If you anyway think this is enough for you and you don't like the method I have described, write to the Partition Manager mailing list (you have to be subscribed) and you will find people who will explain it to you.

Comparisons to other programs: LILO, BOOTSTAR and BOOTIT
LILO compared to RPM + Trombettworks workaround: [I say LILO but it's the same with the other 100 similar boot managers in the world]
LILO loses because:
1) No more than 4 primary partitions, so it's not guaranteed you can have more than 4 OSes. (e.g. Windows requires a primary partition).

2) If you remove one partition all the partition letters slide, messying up all the links to programs you had, which means deeply influencing the other OSes. Same if you want to add a partition in the middle. Substantially, if you want to add a new OS, most of the times you can only delete the content of a partition (remove a current OS) and replace it.

3) All OSes are visible one to the other. There might be problems in installing an OS twice. E.g. Win98 will refuse to install if it sees a fat32 partition already present. You can work this around by changing the active partition, nevertheless like this you are using two of the only 4 active partitions you have.

* In short: all the OSes deeply influence one the other, you are almost fixed with the initial configuration, and you limit the total number of OSes you can install. This prevents you doing a REAL multi-boot.

4) Many other things I don't know. :-)

There are lots of fans of the LILO boot manager, who see these described problems as secondary [1,2] or enough workaroundable [3]. If you are a good LILO user you surely can decide by yourself.
I still can't see real advantages in using LILO instead of this method though, while I would fear the lack of reversibility and reconfigurability.

BOOTSTAR compared to RPM + Trombettworks workaround:
Bootstar is a nice piece of software, which has the aim to do exactly the thing this page describes (together with RPM and BOOTIT they seem to be the only programs of the world which allow this). Unfortunately loses the competition against RPM because:

* Has got lots of incompatibilities with hardware which come out after some time (sometimes even after you buy it!). Incompatible with ASUS motherboards, with some SCSI controllers and other things I can't remember. I suspect of dirty programming techniques which save data in the motherboard EPROM.
* Not at all flexible in managing partitions. Impossible to modify entries in your partition table, impossible to resize. If you want to resize or move a partition you have to LOSE all the content. Very bad.
* You don't have all the low-level control you have with RPM.
* Costs 15$ and has a 30 days evaluation period, while RPM costs 10$ and has got a 10 years evaluation period which makes it almost freeware.

BOOTIT compared to RPM + Trombettworks workaround:
Bootit is horrendous. It's in theory able to do what we are doing but it's incredibly full of bugs and totally uncomfortable to use at low level. Don't try it if you care about your things. Furthermore it has the cheek to cost a fortune! Price seems inversely proportional to quality in this kind of things.

Ranish gets my "Coolest guy in the world" award for giving RPM away for free!

Back to Trombettworks Software