[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 http://www.ranish.com/part/. Go there and
download the latest version.
----------------------- ATTENTION PLEASE - VERSION
2.42+ ----------------------- At the time I wrote this tutorial, the latest version out was 2.38 Beta 1.9 which didn't support more than 4 primary partitions. In order to break this limit I invented the workaround based on paper, described below. Since version 2.42 (released March 2002 by Muthu) the new Ranish-Muthu Partition Manager is able to remember the parameters for 31 primary partitions, so the paper (which was used for writing down the parameters) is probably not necessary anymore. But with the exception of the trick of the paper, all the rest of the tutorial is still very valid because the concepts behind the real-independent-multibooting have not changed. And I don't want to rewrite the tutorial also because explaining things in the old way will make you better understand how things are really working at low level. So please go on and read all the tutorial as it was. Just suppose that there is something which writes down the parameters instead of you and so also interchanging the partitions becomes faster... but not technically different. At the end of the tutorial there is another gray box like this one which explains you what exactly changes with the new versions. ----------------------- ATTENTION PLEASE - VERSION 2.42+ ----------------------- |
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):
# | CYL | FsType | Size | Description |
1 | 1-50 | 06:Fat16 | 401M | Win98 secondary installation (rescue OS) |
2 | 51-90 | 06:Fat16 | 321M | NT4 secondary installation |
3 | 91-170 | 06:Fat16 | 642M | System partition for Win98 primary |
4 | 171-370 | 06:Fat16 | 1.6Gb | System partition for NT4 primary installation |
5 | 371-620 | 0B:Fat32 | 1.91Gb | System partition for Win2000 RC2 |
6 | 621-996 | 83:Linux Nativ ext2fs | 3.020Gb | System + data partition for Linux |
7 | 997-1023 | 82:Linux Swap partition | 216Mb | Linux Swap partition |
8 | 1024-2192 | 0C:Fat32 LBA | 8.94G | Common partition seen by everyone, with the data |
9 | 2193-End (End=2193,144,63) | 0XF0:BootManager | 1.4M | RPM Boot manager partition |
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!