Multi Boot Partition Tricks with the Windows Bootloaders


or

Fooling Windows Setup and Getting Away with It.

 

Say you’re wanting to run multiple installs of windows on multiple partitions, but you want to make sure that one install of windows doesn’t affect the other in any way. Why would you want to do this? The perfect example is if you’ve got a new version of windows currently installed and you want to dual boot an older one. Another reason to do this is to enable proper testing of a OS in an automated scenario.

 

A quick disclaimer – all the next info is specifically to do with x86 and x64 systems – ia64 is a completely different kettle of fish and deserves it’s own post at a later date.

 

If you install an OS that’s older than the currently running OS in a dual boot scenario, Windows Setup will overwrite the boot files from the newer OS with the older OS files. Generally, Windows bootloaders are backwards compatible but not forward compatible, so if you want to be able to boot back in to your original OS you’re pretty much hosed. For instance, if I’m running Windows 2003 Server SP1 and I run an install of Windows XP RTM, the boot files on my current system will be overwritten with the XP RTM versions. Even though the boot.ini file will be updated to contain links to both OSs, attempting to boot into Win2k3 will fail as the bootloader files are much older than the operating system files. Most of the time this is only an issue with major OS releases, servicepack releases will generally be compatible with other releases of the same OS.

 

There’s a couple of interesting things about the bootloaders and the basic sequence that happens when you turn on a machine. I’ll just quickly run through a functional sequence here:

 

1)      Computer turns on and runs BIOS checks, determining which hard drive it has set to be the primary

2)      BIOS checks this primary hard drive’s partition table, looking for the partition that is currently marked as the active partition

3)      If the active partition is located, the loader is looked for in the root of that drive. The loader may or may not be a windows loader, so this is where the windows specific stuff comes in. If it’s a windows loader (for NT this is the hidden, system, readonly file ntldr) then the loader will typically (at least for a full OS, WinPE is a slightly different story I’ll talk about later) look for a file called boot.ini also located on the root of the drive.

4)      The boot.ini file shows the partition that actually contains the windows version to boot. The loader will go to this partition and search for the directory listed in the boot.ini for the Windows loaders and proceed with them.

 

This sequence is interesting from a dual boot scenario because the bootstrappers rely on a single partition (the active one) to boot multiple OSs. This can cause a number of problems, specifically:

 

1)      The older OS overwriting the newer OS’s boot files as described above.

2)       If you’re testing a new OS by installing it from a known good older OS (what we call the “Safe OS”) and the new OS setup overwrites your Safe OS’s bootloaders, you’re relying on a potentially untested operating systems’ ability to successfully install and not have a buggy loader. This can be a very bad assumption to make, especially when restoring the original Safe OS configuration can take upwards of 40 minutes.

3)      If you’re testing or using WinPE as a Safe OS, the current WinPE bootloader does not give you the ability to use a boot.ini file so there’s actually no way this will work.

 

So, having said all this, what’s a good solution? Well, the best way to do this is to make sure the test OS never overwrites the safe OS’s boot files. Before initiating an install, we make sure the Active partition is changed to the partition we’re planning on installing to.

 

How is this accomplished? Through the magic of diskpart. This is a fully scriptable command line disk and partition management tool that is included in Microsoft operating systems from Win2k up, including WinPE. To script diskpart, create a text file with one command per line and pass it in with the /s parameter. One tip – you only need to use the first three letters of any diskpart command, so for instance “select disk 0” can be abbreviated to “sel dis 0” – just a quick hint for those wanting to save some keyboard time. To activate Partition 2 on Disk 0, the diskpart script would be:

 

Select disk 0

Select partition 2

Active

 

It’s that simple. One fun thing to be aware of is that the disk numbers are generally zero based, but the partition numbers are generally one based. Also, volume numbers (which generally correspond to partitions) are zero based, so it can be very easy to get confused.

 

Once the partition is marked active, it’s time to fire off the Windows install. There’s a problem though – winnt32.exe (the windows setup executable) tends to freak out when you’ve changed the active system partition from underneath it. Here’s where some extra command line parameters come in handy. Call winnt32.exe with the syspart parameter as follows:

 

winnt32.exe /syspart:d:

 

This will let Windows setup know exactly where it should put the system files.

 

Booting back and forth with this configuration

 

This config is only really useful if you’re running beta versions of Windows, or you really don’t want installs screwing around with your boot files. The main issue is that you need to change active partitions to boot between operating systems which can be a major pain. If you’re using WinPE, however, this issue is a given. If you’re not, you can manually modify your boot.ini to allow an easy boot back and forth. (If you’d have installed your 2 windows in the correct order originally, ie. oldest version first, without using the active partition trick setup does this next part for you.)

 

A typical boot.ini file looks like this:

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect

 

Just modify this by adding in another entry under the Operating Systems heading, as so:

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(2)\WINNT=”Microsoft Windows 2000 Professional” /noexecute=optin /fastdetect

 

If there’s more than one entry in the OS section the bootloader will display a menu, then after the timeout time (in this case 30) will boot the default entry (in this case XP).

 

– mike (Michael Warmington, mwarm@microsoft.com)


Comments (7)

  1. Puri says:

    I triple boot a lot on my work and home pcs. I will go with a 3rd party product like system commander. All the tweaks you mentioned here are good, but they have too much fine print. Not worth it. I am always surprised how MS has no good tool for dual and triple boots.

  2. Zeta Blocker says:

    Easier multi-booting == easier GNU/Linux migration! No siree-bob…

  3. mike says:

    Agreed, if you’re using a 3rd party product it can be much easier to use, however if you’re wanting to automate windows installations you’re pretty much stuck with whatever windows has in-box. Everything I’ve done above is possible to both script and run with just the standard windows install.

    Thanks for reading!

    – mike

  4. Matt says:

    I created a fresh NTFS partition to install Windows Server 2003 Standard as a dual boot with Windows XP Professional. I did a startup to the win2003 cd and installed to the new partition. I can load my "safe" XP install but the server says the kernal (ntoskrnl.exe) is corrupt and I should reinstall. Any suggestions?

    -BTW, I also has Linux Mandrake on an extended partition, that I moved over to make room for the server. After installing the server, it kicked off Linux’s boot manager. Is there a GNU boot I can install to switch effeciently between these three operating systems?

  5. Jason says:

    I believe your problem here is that you are loading Windows Server 2003 first. What you’d want to do is load XP first, then Server. This way the loader won’t get clobbered by an older loader.

    Good Luck!

  6. Mike Dimmick says:

    The recommended technique last time I looked at it was to use the Windows boot loader to load the Linux boot loader. Set up LILO or GRUB to write to the boot sector on the partition, not the MBR. For example, write to /dev/hda2 rather than /dev/hda. Then, extract the written loader to a file using dd:

    dd if=/dev/hda1 of=/bootsect.lnx count=1

    Then copy bootsect.lnx to your boot volume. If the boot volume is NTFS you’ll need to go via some other media because, IIRC, at present Linux does not have a read/write NTFS driver. I wouldn’t risk it!

    Now you can add a line to your boot.ini that reads something like:

    C:bootsect.lnx="Mandrake Linux"

    This feature is actually for DOS/Win9x dual-boot compatibility, but it works OK for Linux as well.

  7. Shivkumar Mudaliar says:

    Hi, My problem is that I have two hard disks, one a 40gb which already has windows 98, with dual boot of windows xp, both with fat32 partition. Now in the second hard disk of 80 GB, I wish to install Win2003 Server Enterprise Edition, with NTFS partition. How do I go about setting up win2003 server, since it does not install from windows 98. Besides do I have to partition the second hard disk entirely as extended partion, to install win2003 server. Also if I am able to install win2003 server, and later I run the os, and wish to view files in the fat32 partitions of the first hard disk, is there any other processes to be followed?

    Shivkumar (srk_80@indiatimes.com)