At a very high level and subject to some inaccuracy:
The MBR code is what gets control first as the boot image is loaded from the disk. The MBR itself is not very big, so the first thing any MBR code does is intialize then load something else. In the case of grub, it has stages, and the MBR code is stage 1. It loads stage 2 which is far larger and smarter, can read the grub config files from disk, and determine how to start the next stage.

A Chainloader is only required when the Grub loader is handing off control to a different boot loader, this was required to load some ( perhaps all) Windows and DOS versions in grub v1. I am not sure if that is ever required in grub 2, or where else it might have value. In general, chainloading is a hack and not the best option. At times you have no choice, and a good hack is all that works, but dirrect support in grub is better and always improving.

Is there a need to increase either MBR size or size of Grub to accommodate three Operating Systems on one hard disk? eg
2 linux distro's and one Windows? Only one swap required in this situation?

You can't increase the size of the MBR, as far as I know (or GRUB), if I'm understanding what your asking here correctly.

I don't think Windows can use a Linux SWAP partition and in Windows as far as I know, the SWAP space is normally in the file C:\pagefile.sys

I can confirm this. I have run several multi-boot machines with Windows (though I have no windows other than NT4 available right now) and while multiple linux distributions in multi-boot can share one swap partition every Windows instance requires and builds a unique hidden pageswap file.

The MBR is fixed in size and location by the original disk format specifications from way back when IBM-DOS first supported hard drives. It may have originated earlier. At that time it only needed a single sector, so that was all that that the specification called for.

When things got bigger the MBR did not (because the BIOS code was written to support that specification and had to load from that MBR during IPL) so the MBR code loads a second stage boot code from a somewhat arbitrary disk location. The system is perfect for DOS, works well with Windows and OS/2, but not so well with anything else.

Replacing the MBR code with another loader is trivial, and LILO, GRUB (1), and GRUB2 are fine examples. Each of these has a stage 1 in the MBR, a stage 2 from the disk that can display a menu and then load a kernel (stage 3?) based upon the results. That kernel can be the kernel or native OS loader for an arbitrary operating system (Windows, Linux, or BSD are common).

One thing you do not want to do is home GRUB in a linux partition that you plan to blow away. Decide on one as a base that you will run for a long time, and let an secondary or short term distros come and go an later partitions. If you do not plan it well, removing the distribution that homes your grub can result in having a bad afternoon. Easy enough to fix, in the end, but better to avoid the problem.

My current laptop came with WinXP, runs a Intel Centrino Duo (not terrible for when it was new, but not exactly a powerhouse). After running dual-boot WinXP and MINT for a time, I loaded it with VSIDO in a total reload eliminating Windows. Today I base it on Q4OS Linux, with multi-boot loading for FreeDOS, KolibriOS, and I am playing with adding ReactOS and TinyCore Linux. GRUB2 homes on Q4OS handles loading all of these nicely, once configured (TinyCore in Persitent mode, like KolibriOS, is not autodetected: the others are). I have, in the past, run FreeBSD versions and GRUB2 detected and handled them nicely. Really, if you do not pull the rug out form under it, you should find that it takes care of your booting needs very nicely.

Totally agree with the above 2 posts from jsbjsb001 and wpeckham. wpeckham gives a very clear explanation of how GRUB works and how it depends on the MBR in a BIOS based system.

Cheers,

Pageswap file resides in Windows own swap?

By don't "home" you mean "don't let it be allocated"?

Can the windows secondary bootloader be deleted from first sector? If GRUB becomes secondary preferred bootloader does that mean I don't need windows secondary bootloader on dual Win/Linux OS?

I keep a small boot partition for Grub's MBR component to point to, and chainload various OSs from there. Each OS's bootloader goes in that OS's root partition. Requires manual editing of the boot partition's grub.cfg entries as I change OSs, but means I don't have to worry if I decide to blow away any of my installed OSs.

linux-man, what they're saying is that you must be sure that Grub resides someplace that you won't blow-away if you install a new operating system. Put it into a small partition that does not contain anything else.

- - -

Windows has its own very-funky second stage boot-loader, NTLDR.SYS, I believe, which Grub does know how to pass control to.

At one client's shop which used a lot of Windows servers, they actually installed Grub (on a very small independent partition, as noted previously) and used it as their primary boot-loader in order to start Windows. They said that they liked the flexibility that Grub gave them when things went wrong. "Microsoft just assumes that everything will work perfectly all the time," they said.

Hey again linux-man,

Windows swap space is in a file in the Windows main ntfs file system, located in the c:\ directory, called pagefile.sys

As explained in a previous post, this is just the poster's warning to not install the stage 2 files of GRUB (its main program and configuration files) on a partition that you are likely to delete or modify.

Do not touch the Windows boot loader. GRUB will pass control to the Windows boot loader (this is what chainloading means) when you select Windows from the GRUB menu of bootable operating systems.

Finally, just out of curiosity, have you actually tried any of these suggestions as of yet or are you still collecting information ?

Cheers,

Yes,I'm at collecting information stage. But I have partitioned the drive with windows as per
prior discussions. Backups done.

Would there be any benefit in making separate partition mount points for the following?
/tmp
/var
/opt
/usr

Re partitioning, if you only have one disk and its a home system, I wouldn't bother, except maybe for /var/ which contains /log, /spool dirs etc, which can fill up if you get a runaway process or you don't setup logrotate well enough.
NB: normally the default setting for logrotate is good enough unless you do get a runaway process as mentioned.

HTH

Hi linux-man,

I agree with Chrism01 above - for home systems I would tend to keep it simple and just use a root partition or, at the most, a separate partition for /home. As others have previously pointed out, setups for a business environment, particularly for servers, benefit more from more granular partitioning.

Cheers :-)

Is having a separate /root partition more susceptible to a risk fragmentation of the disk?
How large should I partition for multi distro setup? 2 linux, 1 windows
/
/boot
/home
I have 200GB to play with for linux.

I read this somewhere:
"If you often install a new distro, I recommend to separate 1 empty ext4 partition for special programs or their configs --such as virtualbox disk files, your projects, etc. Because some distro installer may be unstable and your home data may be destroy.
It is my bad experience." True/False?
What would this empty ext4 be named? How large should it be (if I did one)? Should I do it too?

The "root" partition would always be your "/" partition, not "/root". The "/root" folder is the "home" folder for the root/superuser account, which often confuses people, because it's the same name as the "root" partition (which are NOT one of the same thing).

I'm not sure you would have more file fragmentation by having separate partitions, I don't think that's what it would mean anyway (I don't think you would have more fragmentation, personally). Linux file systems, (like ext4) are pretty good in terms of NOT fragmenting the disk, maybe large files (video files, etc) would be more likely to fragment, than smaller files, like files on your "root" partition (which mostly are going to be fairly small/smallish, if that makes sense) in terms of today's standards.

It's normal to have a separate "/home" partition and there are benefits to having this sort of setup, but having said that, it is a matter of personal choice, as there is no right or wrong answer, as far as that goes. You will more than likely be safe accepting the defaults proposed by your distro's installation program. Naming your partitions, helps ID them when looking at them in programs like (but not limited to) Gparted.

I personally do name my partitions for the same reason as stated above. You can look at the size of them as well, to help ID them.

1. Generally, linux partitions do not suffer from fragmentations that impact performance or life significantly the file system drivers handle reducing fragmentation in normal use transparently: as long as there is sufficient free disk space in the file system.

2. The purpose for extra partitions is twofold: system protection and datas protection - both using segregation. The extra partition gives you a space that you can cheaply back up or transfer without impacting the OS and installed applications. The system is protected because that extra file system filling up and crashing will NOT crash the OS.

3. I have seen these partions named home and mounted /home and used to host the user folders, /data or /opt and used to host third party applications or data, and other patterns. There is no hard & fast rule, it depends upon how you want to run and what you use your system for.