Quad boot

Hi there!

About the "crashed" discs - is only the operating system on these drives completely jammed, or did the drive hardware crash? If you're unsure, you should test the drives with the diagniostic tools provided by their respective manufacturers - and replace them if they are reported as bad.

Point 1 is perfectly fine. ;-)
Regarding point 2 and 3: It's not only about craeting partitions and formatting them - bus also about partition IDs: Every partition carries a flag in its partition table entry which indicates the operating system and/or file system this partiton is intended to use. If an operating system setup comes across a partition flagged with an ID it doesn't know, it may-  or may not - offer you this partition as an installation target. I mean vageuly to remember that at least Windows 2000 and XP won't install into a partition which carries the ID 0x83 (which means that this partition is intended to be formatted with a Linux file system)!
As a result, you should not create all installation partitions before installing any operating system - but instead, you should use the tools provided with each OS to create the target partitions for the different systems.

NTFS is the native file system for XP/Vista - but NTFS is not the same as NTFS; so there are different versions of this file system. Thus, you best format the XP partition using the XP installer, and the Vista partition using the Vista setup.
Mac OS X uses HFS+, as far as I can remember - you best create this using the MAcOS X setup.
About Ubuntu... Since it is based on Debian, I think it uses ext3 as its default file system; usually, this system does well under most circumstabnces. However, if you have extremely large files on your Ubuntu partition (where "extremely large" means several of gigabytes per file - which usually won't happen on the system partition), you should consider switchuing to e.g. XFS (but keep in mind that this might be problematic with some boot loaders).

A primary partition, formatted as FAT32, should do fine.

Works fine for me (Win2000, Debian Sid & FreeBSD 7.0 on one hard drive).

During the Ubuntu setup. The installer should ask you whether it should install GRUB in the MBR or not; just answer this with "yes".

That's the order I'd do it. First install one Microsoft OS. Then use the Linux command-line FDISK to change the partition ID of this installation partition to something Windows does not know - 0x83 is fine, as I said above (dowin this with the command-line FDISK will only change the ID in the partition table, bu will leave the data on the partition untouched. I don't know if GParted is able to change just the ID without touching the file system!). This will hide the first Windows partition from the second Windows setup - as a result, the second Windows installation will write its boot loader to its own partition (If you don't change the partition ID, the second Windows installation will try to include itseld in the boot loader on the first Windows partition - which will very likely fail ist the first Windows installed is Vista since the older XP does not know about the new Vista boot loader. Even worse, if you decide to reformat the first Windows partition, the system in the second Windows partition won't be able to boot since it has no boot loader of its own!). Change back the partition ID afterwards. Since Windows tends to write its own code to the MBR, no matter if there is already another boot loader present, you should install Windows first - otherwise you could just damage your GRUB.
Then install MacOS X and finally Ubuntu. Put GRUB into the MBR of the Ubuntu installation drive, and set this drive as the BIOS boot device - and you're done.

ACK.

It is definitily best to create and format each installation partition using the respective OS setup program! This way, each installation partition will carry the right ID in its correspinding partition table entry. Unless you don't know exactly which ID to use on which partition, you should not use GParted to create the partitions!
Instead, simply start the OS installation without creating any partitoon beforehand and make the partitions and filesystems during installation.

I'm not sure if GParted can do this job - I haven't looked at it closely enough. However, the "standard" Linux fdisk (which should be available on the GParted Live CD on the command line) can definitely do the job.
At last, I don't think you'll find a tool for setting the partition ID on your WinPE boot CD - unless you've included some third-party software for this job on the PE CD. In the past, Microsoft didn't care that much about Dual-Boot installations or other operating systems than Windows on a computer, so I'd be really surprised if they shipped a proper partition manipulation tool with their OS!

Correct. You create and format the installation partitions using the tools integrated in the setup tools for your opertating systems - and install into the shiny new partition afterwards.

Should be. After writing all your system files and applications to the Ubuntu partition, the Ubuntu setup should ask you where to install GRUB (sorry for not knowing in detail, but I'm running "pure" Debian, not Ubuntu... and Ubuntu deviates from the "Debian ways" in some points).
However, don't confuse installing GRUB in the MBR (of the hard drive Ubuntu is installed on) with installing it in the partition where Unbuntu is installed! The MBR is the very first 512 byte sector on the hard disc - and it is located outside any partition.
If you install GRUB in the Ubuntu partitioon, this partition must be flagged as "bootable" in the partition table, and you need some code in the MBR to chainload this partition.
If you install GRUB in the MBR, you won't have to care about the MBR contents.
By experience I'd say that installing GRUB in the MBR is the less painful way.

Not the Ubuntu partiton, but the hard drive where Ubuntu is installed. The BIOS does not know about partitions at all - it sees a hard drive simoply as a chain of 512 byte sectors where data can be stored.

As I said before, I'd use the standard Linxu command-line fdisk to safely manipulate the partition IDs (of course, you could use a hex editor as well... ;-) ).
To include the other operating systems in your GRUB boot menu, make sure that there is something like

title           Windows XP
root            (hd0,0)
makeactive
chainloader     +1

title           Windows Vista
root           (hd0,1)
makeactive
chainloader     +1

title           Mac OS X
root            (hd1,0)
makeactive
chainloader     +1

in /boot/grub/menu.lst on the Ubuntu partition. In these entries I've assumed that both Windows systems are installed on the first hard drive (the one that the BIOS sees as the first drive - you can check this in your BIOS setup or during Boot-up when the BIOS lists the hardware it has found) - XP in the first and Vista in the second primary partition. MacOS X is assumed to reside on the BIOS second drive in the first primary partition.
It may well be that the Ubuntu installer adds such blocks for the operating systems it detects itself - so you should walk through the file before modifying it.

Hi cmdr,

Sure, it's not a big deal - but if you're not used to using a disk editor, you can easily get somewhat confused by those blocks of strange values filling up the screen. And even if you know how to use such a tool and how to do the manipulations - why not use a more comfortable tool that can do the same?
After all, both tools can and will do the job - it's up to LjStef which one to use.

That's why I suggested changing the partition ID aftet the first Windows system is installed: The second Windows setup will then simply ignore the partition where the first system is installed (everything Windows itself knows about e.g. Linux partitions is that it can't use them - so they're left alone). As a result, the second installed Windows system will put its boot loader and config files completely into its own partition and not mess with the firsat installed system.
OK, the second installed Windows system may overwrite the boot code in the MBR - but since GRUB will be used for OS selection and booting afterwards, the Windows MBR code will be oveerwritten again (or simply ignored if GRUB in installed on another drive).

The partition type (primary or logical) is relevant for assigning the drive letters only for the DOS-based WIndows versions. These versions (up to Windows ME) first went through the installed hard drives, assiging a drive letter to eash primary partition (since they only suported one primary partition per disk, each disk got one letter), starting with C: for primary master, D: for primary slave or whatever is the next hard drice, and so on. Then they cycled through the drives again, assiging a letter to each logical partition on primary master, then every logical partition on the next drive got its letter, and so on. There was no way to manually modify this scheme!
Since Windows NT, drive letters can be freely assigned using the built-in Windows tools - with two exceptions:
- The partition containing the Windows boot loader will always be drive C:;
- the partition contaiing the Windows installation can not be changed, too, but may have any drive letter assigned automaticylly during windows set-up.
In mot cases, you have only one Windows installation on your machine, so boot partition and system partition will be the same (thus carrying the letter C: ), but if you have two Windows installations which both use the same boot loader (which is the default if you don't touch you partition IDs), the partition containing the boot loader will be drive C:, no matter which Windows installation you boot.
If you boot the installation resising on the boot loader partition, you can assign any drive letter to any partition (except C:, wich can't be modified), but these assignments will only be valid for this Windows system.
If you boot the second Windows system, this one does not know about the drive letter assignments made on the first installation, it will see its own system partition as e.g. D:, and this system partition's drive letter can't be changed, either.
Using labels on your Windows partitions is a very useful thing just because of these "per-installation" drive letter assignments - it helps you to keep track and manually synchronize your letters.
So much for background information - I don't know it is helpful fou LjStef, but maybe it helps to clarify a bit how things work.

Hi Dino18!

First, you need to know the device name for your Windows hard drive. If you don't kow this, just start up GParted, wait for it to scan the available mass storage media, and cycle through the drop-down list in the top right corner of the window until you've found your Windows hard drive (you should recognize it by the partition layout and file systems used). Note down the device name - within this post, I'll assume it is /dev/sda, but of course you'll have to adapt it if yor device name differs.

Switch to the command line and start up fdisk:

fdisk /dev/sda

fdisk is then mainly controlled by single-key commands (if it expects you to give some other information, it will tell you so). "m" gives you a brief overviwe of the avaiable commands.
First, you should use the "p" command to print the current state of your partition table; you may want to write down a copy of it.
Identify your existing Windows partition, then select "t" (to change the partitoon type), supply the partiton number, and enter the new (temporary) partition type - e.g. "83" (this already is the hex value fdisk wants to know - no need to convert anything).
Write the changes to your drive using the "w" command.

Then install your second Windows; afterwards, change the partition ID of your first Windows partition back.

After installation of the second Windows system, make sure all systems are listed in your boot loader configuration - may it be GRUB (if you also have Linux installed on that box) or the Windows boot loader (if you don't use Linux).
If you have to go with the Windows boot loader, make sure you use the partition with the more recent Windows installation (if you have Win2000 and WinXP installed, label the XP partition as bootable and remove the boot flag from all other partitions using the Linux fdisk). Then boot up this installation and enter your second Windows system in the boot loader configuration (c:\boot.ini - which is a plain ASCII file - on Windows NT/2000/XP; I don't know how the new Vista boot loader works, but I know for sure it's a bit more complicated than simply hacking a text file. So maybe one of the Windows experts must help you if Vista is involved somewhere...).

Hi!

I don't know a way to install any Windows system into a logical partitition - to my best knowledge, Windows must be installed to a primary partiton.
You can have a maximum of four primary partitions per hard drive - but then you can't create any logical partitions on that drive. If you intend to use logical partitions, you can create a maximum of three primary partitions; the fourth partition table entry must then be used for an extended partition which serves as a container for the logical ones.

Please keep also in mind that Linux [c]can[/b] be installed to a logical partition. Forthermore, it usually needs at least two partitions for installation - while Windows uses a file on its system partition as swap space, Linux uses a separate partition as swap.

And also mind that NTFS support on Linux is always a bit risky since the NTFS driver has to developed using Reverse Engineereing - if Microsoft introduces new features in their NTFS file system (which they usually do with each Windows version), it will take a while until Linux can handle these new features. Using an outdated NTFS driver on a Windows partition could possibly damage the file system!
The other way round, Windows can't handle the Linux file systems natively - there are driver for ext2, but to my knowledge, that's all.
So if you wish to install both Linux and Windows, you should add another partition (primary or logical does not matter), fomat it as FAT32 - and use it as "data exchange" partition.

Counting all your operating systems and taking into account the Linux installation and the data exchange partition, you'd need two hard drives:
- One drive to hold four Windows installations (four logical partitions);
- The second drive to hold the remaining Windows system, Linux system and swap partitoons, and data exchange (which in this case can all be primary partitions. As mentioned before, Windows MUST be installed to a primary partition; Linux should be, since this can simplify handling your boot loader configuration; and the Swap and Data partitions can either be primary or logical - it doesn't make a difference there).

Hi,

I agree totally, this statement is true !

But if you install e.g. Win 2k or XP to another harddisk (primary bootable partition, even on a second PC) up to the stage, before it gets "married" with the hardware on one of its last necessary bootings  (you can set a parameter, which stops installation there !), and then copy all files of this incomplete "virgin" installation to another drive / partition or logical drive in an extended partition(!), you are able to get it working on all these locations! You only need to transfer "NTLDR", "NTDETECT.COM" and "BOOT.INI" to the bootable, primary partition of that HDD, which must of course have a Windows compatible file system ( e.g. Vista !). And you have to alter "boot.ini", which is not very complicated, even tolerates trial and error, if there is another working OS on this harddisk to edit this file. Best of all : Vista "bootmgr" integrates the content of a found "boot.ini" (in its root folder) automatically into its bootmenu ! Then do the last bootings (with Vista) on the new location ...  and you have a working Win OS on an extended partition !

You do NOT believe it ?
Do a simple experiment :
If you have a working WinXP system, which has (FAT32 or NTFS) logical drive(s) in an extended partition, create a folder "WINNT" with a subfolder "SYSTEM32" on a logical drive, where you put a copy of "hal.dll" from your "%windir%\system32"-folder on your WinXP-Partition. Rename that copy "hall.dll" for the first part of the experiment. Then edit "boot.ini" on the root folder of your WinXP-partition and add a new last line under "[operating systems]" :

multi(0)disk(0)rdisk(0)partition(2)\WINNT="experimental"

where partition 2 is the extended partition (might be 2 to 4). If you have more than one harddisk attached,  you might also have to adapt "rdisk" to the value of the appropriate disk as you see it in "boot.ini". Look, that the "timeout" is long enough, but DON'T CHANGE ANYTHING ELSE ! Store "boot.ini", reboot your PC. Choose "experimental" in the bootmenu, and you get a message, that "hal.dll is missing". For the second part of the experiment  restart to WinXP, rename "hall.dll" on the logical drive to "hal.dll" and reboot to "experimental" again. Now you get a message that "ntoskrnl.exe could not be found". That means "hal.dll" was found and started !  The normal OS initialisation process went on !  Don't forget to restore "status quo ante" on your system (boot.ini, testfolder/-file).

If you use "GRUB" as bootloader, you only have to "chainload" "NTLDR", wherever it is, and you get Win 2k/XP running.

Bye
cmdr

Hi!

On a SATA drive you won't find any jumpers to determine if the drive is "Master" or "Slave"... or "Primary" or "Secondary". It's all determined by the SATA port the drive is connected to - so just re-plugging the SATA cables will be enough.
However, it is possible that you break your XP installations this way: After re-plugging, XP won't be installed on the first hard drive any longer, but on the second drive. I don't know how closely XP gets "married" to teh system during setup, but if there's information like "This XP is installed on the first hard drive in primary partition 2" is stored somewhere in the system, XP won't find its system files any longer after this procedure - and will most likely fail to boot.

After all, it's up to you:
- You can try to install Vista to the first hard drive (with the XP installations on the same disk);
- you can try to install it to the second drive (with the XP drive still in the first place, so you won't change the location where the XP system files can be found);
- you can re-connect your drives, install Vista to teh first drive, and hope that XP still boots from the second drive.
Whatever you do, be aware that it's kind of experimental - it could be necessary to start over again from the beginning (so to say, wirth blank hard drives)!

By the way, GRUB ist definititely able to boot operating systems that don't reside on the GRUB installation drive.
And if you read the GRUB documentation you'll find something about BIOS drive remapping - this means that GRUB is able to change the order in which your hard drives are visible to the BIOS before booting an operating system (in theory, you could boot DOS from the second hard drive using this method). BE aware that this may not work for your XP installations since XP does not rely on what the BIOS reports about your hardware! To speak in trerms of your re-plugging idea, your BIOS may report your XP drive to be in the first place (since GRUB can modify the drive assignment at BIOS level before handing the boot process off to the XP boot loader) - however, since XP talks directly to your SATA controller, it will see that the BIOS is lying and that the XP drive is in fact connected at the second port...

About adding a partition ID manipulation function to GParted: I am not a developer, but I think it won't be a good idea to include this function. GParted in principle is a easy-to-use partitioning tool, and making it possible to separate the partition ID from the file system would make the tool too complex in my eyes.
In practice, you'll need a partition to carry a given ID if you use sa specific file system on this partition; otherwise the partition won't be detected by your operating system(s) at all. Making it possible to manipulate the partition ID will make many people think they can "convert" between file systems with nothing more than a mouse click - and then leave them wondering why nothing works.

The problem behind this is that you have several hierarchy levels of software that depend on each other. You could think of partitions as storage boxes you have in your kitchen. One contains rice (and is labelled accordingly), another one bread, the next one sugar and so on. The contents of the box resembles the file system used on the partition while the writing on the box represents the partition label. If you want to cook a risotto (~use a drie from inside Windows), you need rice for it (~the partiton must be formatted using NTFS), and Windows is clever enough to look at the partition labels instead of trying to read each partition (so it opens only the boxes with "rice" written on them).
GParted keeps the boxes' contenty and label synchronized, so if you use GParted and afterwards Windows opens the rice box (partition carrying an "NTFS" partitoon ID), it will find rice (NTFS) inside and be happy.
But if you are able to modify the boxes' contents and labels inedependently, you vertainly will end up with Windows looking into the nox labelled rice, but finding sugar inside - which it can't use, so it won't work.
You have the same thing with regular files on Windows: Windows relies on the file name extension to describe what's inside the file. As a result, you often see people "converting" e.g. a wave file to mp3 by just changing the file name extension - not understanding that this does not change the internal structures and contents of the file! The same people then are stunned if you "convert" their mp3 to e.g. an Excel spreadsheet (which changes the file's icon, so the "conversion" must have worked) - and Windows tries to open it in Excel, which of course fails...

So my opinion is: Keep things simple in the easy-top-use tools (which means, keep these tools easy-to-use), and do complex things that require a lot more flexibility with other, more flexible tools - which will definitiely be less easy to use, since flexibility and feature-richness have their price! If you compare e.g. the built-in Windows firewall to Linux' netfilter/iptables, you'll find that the latter is much more powerful and flexible and that you can do things in it that simply aren't possible in the Windows firewall - since adding all the functionality to the Windows firewall would turn the easy-to-use soultion into a feature monster like netfilter. There are approaches to hide netfilter's power behind a simple user interface - but these interfaces typically give you access only to a fraction of what can be done on the command line!

Hi!

The idea behind playing around with the partition IDs is quite simple:
The first Windows system you put on your drive installs its boot loader inside its own system partition - so far, so good. Everything you need to boot and run this Windows installation resides on the same partition.
If you then install a second Windows system, it usually recognizies the first system's boot loader - and thus doesnot install a boot loader on its own, but insteads registers with the first systems' boot loader. As a result, the files required to boot & run the second Windows installation are distributed across both the first and second partitioon: The first partitzon contains the boot loader, while the remaining system files are stored on the second partition. So if you jam the first partition, you'll likely lose the ability to boot both Windows systems.
You can evade this additional dependency by hiding the first Windows installation from the second system's setup routines (which can be done by simply setting the partition ID that Windows recognizes as "not compatible with me"): In this case, the second system's setup will install a new boot loader to the second partition, and this boot loader's configuration only contains the Windows system on the second partition, so everything you need to boot this system is storted on the second partiton; the second WIndows installation works completely independent from the first one.

All you have to do after all systems are installed is create one entry for each Windows partition in your GRUB boot configuration file (root (hdX,Y) / makeactive / chainloader +1 / boot) - and each Windows system will start directly from the GRUB boot menu.
The other way round, if you don't hide the existing Windows installations from the currently runnign Windows setup, you'll have only one Windows partiton to enter in the GRUB boot menu. In this case, GRUB will effectively call the Windows boot loader on this partition, and you'll have to select the Windows system you want to use again from the Windows boot menu - making OS selection a two-stage process. You may like this additional step - or think it unnecessary...

Hi!

That's one variant of chainloading: You specify the file name of the boot loader to be started by GRUB. This can of course only work if GRUB knows the file system the second boot loader is stored on.

If GRUB does not knowe about the file system, you can still use the syntax I've used in my post: "chainloader +1" instructs GRUB to read and execute the first sector of the partiton you specified in the preceding "root" statement as the partition to be booted. In principle, this is exactly what tghe "standard" MBR boot code does if there's no GRUB present: Start the boot process using the boot code stored inside the partition that is to be booted.
Since each Windows partition contains a piece of boot code in its first sector, this method should work always! The nice side effect is that you can boot any operating system using this method - provided that it installs a bit of boot code in the first sector of its partition. On my "playground" system, I use GRUB to boot Windows 2000 and FreeBSD 7 this way (besides Debian Sid) - without fiddling around with any chainloader syntak or taking care about file systems (I don't know if GRUB understands UFS2 or the BSD disklabel inside my FreeBSD "MBR partiton" - the "" must be used here since FreeBSD uses the term "partition" in dosk partitioning at another hierarchy level, so confusion is on its way... ;-) )

"Classical" GRUB can also be repaired quite easily if the partition containing most of GRUB's code (and the configuration file) gets corrupted; since the last OS to be installed is Linux (if I remember everything correctly), I'd use "classical" GRUB instead of GRUB4DOS.

Hi LjStef,

Here is the source of that statement. Smaller values might have their origin in software (e.g. AVI-Files) or RAM limitations (3 GB !).

I don't have a good solution for that problem ( split a large file / DVD-ISO for storage ??).