Referencing Hard Drive Partitions
Introduction: We make no apologies for the length of this article since this easily becomes a surprisingly complicated area.
The DOS-based OSes1 use Drive Letters dynamically. The NT-based OSes2 also use Drive Letters (but statically) as well as by numerical integer references. Linux uses device references. Using Drive Letters (as shown by DOS and Windows) is the worst and most confusing way of identifying partitions - particularly if there is more than one drive involved. Drive C: is commonly the "main" Windows partition but this is, by no means, ubiquitously the case nor does this mean it will always be the first physical partition on any drive.
If you really want to get a proper handle on understanding this area you must have a basic understanding of the four standard partition tables found in a standard MBR (Master Boot Record). It is vital to one's understanding to know that the order of the partition tables is of no consequence to how the geometry is referenced. They can be shuffled around and be quite out-of-order without annoying the BIOS or legacy systems at all. If you were to swap the data in partition table 1 with that in partition table 4 then DOS's fdisk wouldn't even blink.
However you must also understand that the NT-based and Linux OSes use the partition tables themselves as the reference points and don't refer directly to the physical positions of the partitions on a hard drive. Thus a Linux hda2 or a WinXP boot.ini's partition(2) might by coincidence reference the second physical partition but what they are actually directly referencing is the second partition table entry. If this fact is not properly grasped and if, for example, boot.ini or GRUB is "misbehaving" for some unknown reason, we hope that you can find out why in the following discussion.
Once you learn how, it can be equally effective (and can often be simpler) to swap the partition tables themselves around then try to edit boot.ini or grub! Different rules may apply if you are using MBR overlay or a third party boot manager and there are particular differences and hazards involved when using NT-dynamic disks or any RAID arrays that involve striping. Some boot managers leave the partition tables untouched - others hijack them in a proprietary way. If the latter is done then you must use that software's own uninstall software to reverse the changes unless you want inordinate difficulty in finding your old partitions.
Preamble
This area is a minefield for the unwary. HardDiskDrive (HDD) partitions are referenced, identified and enumerated in very diverse ways. Different operating systems and software tools not only reference these entities differently but also "do things" differently. If you intend to ...
- troubleshoot HDDs or booting or data recovery
- install operating systems - particularly for multi-boot systems
- create or restore partition images
- alter existing partition structures
- etc, etc, ...
... then it is absolutely vital that you really understand the basics of partition referencing and of the main anomalies and traps involved. Both hard drives and any partitions in them can be referenced:-
- by a name/signature
- by a number
- by a letter of the alphabet
- by their position and size
We recommend using (1) or (4) whenever possible since they are the least likely to be misinterpreted. We deprecate using or at least relying-on drive letters at all (unless that is impossible). We also would specifically warn that numbered sequences sometimes start at 0, sometimes with the number 1 and sometimes with some other variable.
Note that even names/signatures are not immune from conflict. A volume name or id can be stored in (and thus be read from) more than one location. For example, a partition's "volume label" can be written to a location in its PartitionBootSecor (PBS) and/or as an invisible, but specific, Label entry in the root directory of its partition.
Finally note that HDD geometry has a long development history with a lot of anomalies regarding both CylinderHeadSector (CHS) and LogicalBlockAddress (LBA) addressing geometry. Such history is well covered elsewhere on the web for those that want to familiarise themselves further with it and we see no need to duplicate such material here. We would just add that the various thresholds for LBA addressing (nowadays mostly regarding the 48bit-LBA/128GiB/137GB limits) can give rise to another whole range of problems.
Just to be quite clear
In this discussion, primary partitions are defined as those partitions referenced from the four partition-table rows (64 bytes starting at offset 446) in the MasterBootRecord (MBR) which is the very first hard drive sector. An extended partition, being always referenced from one of these rows is thus a specialised unbootable primary partition; it only ever functions as a container.
Logical partitions are partitions included within such an extended partition. Every logical partition is referenced by its own ExtendedPartitionBootRecord (EPBR) - a sector that has similarities with the MBR but which only ever has, at most, entries in the first two of its four partition-table rows: the first for the logical in question and the second to find the next EPBR in the chain. The last one in the chain only uses the first row of its partition-table; just to reference itself. This daisy-chain begins with the extended partition's reference to the first EPBR. Thereafter the second row of each partition-table references the next EPBR in the chain.
The EPBRs (unlike the MBR) are not boot sectors in the sense that they contain no machine code nor any jump instructions. A PartitionBootSector (PBS) is the sector where a partition functionally begins and has different code inside it depending on the format of the partition and on whether it is a boot partition or a straightforward data partition. The location of a PBS is identified by an offset sector number (which has the same value as any "SectorsBefore" or "Hidden Sectors" value). The first primary and all logical partitions are usually to be found 63 sectors (one track) ahead of the MBR or of the relevant EPBR.
All primary partitions are defined by an offset from the start of the hard drive but be warned that logical partitions may variously be referenced from the start of the extended partition, from the start of their own EPBR or from the start of the hard drive itself. This offset value is stored in each EPBR but can also be stored in specific locations inside the PBS itself - a rather occult but potential source of conflict.
We must also add that any drive overlay that "hijacks" the normal code in the MBR can alter the findings outlined in this discussion. This includes not only DynamicDriveOverlay (DDO), used to overcome size barriers, but also boot managers such as GRUB or BootIt-NG as well as when Basics Disks get converted to Dynamic ones and, finally, with some various pieces of malware - in particular the boot sector viruses.
A Major Anomaly
One very important (and largely misunderstood or unknown) concept to grasp is that nearly all modern operating systems (notably the NT-based versions of Windows and the Linux operating systems) identify hard drive partitions via the partition-tables and not directly by the actual physical positions of partitions on the drives. Thus when the "first partition" in a drive is referenced it is the "first partition-table" that is actually directly referenced/enumerated. If that first partition-table itself points to other than the first physical partition (to say the third physical partition on a drive) then referencing what is believed to be the "first partition" will actually reference the third physical primary partition! We will return to this point later because, even here, there are major differences between various Windows and Linux systems. Fully grasping this point can be one of those wonderful "penny dropping" moments that can suddenly explain why previously inexplicable events behaved as they did. Both the primary partition-tables in the MBR and the daisy-chain of logical partitions in an extended primary partition can get out of sequence, with a number of odd consequences. Most of the time the partition-table sequences directly mirror those of the physical partitions and so what is actually going on at a disk level goes by unnoticed.
Specifics for different groups of Operating Systems
(1) MS-DOS and the DOS-based versions of Windows
(2)
Linux
(3) Partition information display examples
(4)
The NT5-based versions of Windows (2000, XP and
2003 Server)
(1) MS-DOS and DOS-Based-Windows. MS-DOS versions before version 3 and non-MS versions of DOS may differ but certainly the DOS-Based-Windows (3.x, 95, 98 and Millenium) only use drive letters for those partitions that they can themselves can directly access. This lettering only relates to visible (non-hidden) FAT16 and FAT32 formatted partitions. FAT partitions are hidden by pre-fixing a "hidden" nibble to the file system's ID byte. Note that any non-FAT/non-DOS partitions will always be effectively hidden from any such drive lettering assignments. One very important consideration with regard to drive letter assignments is that it is a dynamic process. That is to say that at each reboot the letters are always re-assigned according to a set of rules and so if any partitions or hard drive parameters were changed in the interim then the drive letter assignments are liable to have changed in concert. Also note that these operating systems do not officially support more than one visible primary partition. Depending on which utilities you use it can well be that a partition will get hidden or its active boot status changed - "behind your back" - without prompting you. Fdisk can usually sort out such problems should they occcur. Changing just one partition's "status" can thus throw out all the previous drive letter assignments in these systems!
The enumeration of hard drives themselves is not the essence of this page. For now, let us just say that hard drive enumeration also has its own anomalies largely because of the various ways the operating systems "talk" to the sytem BIOS. It is unusual for the BIOS nowadays to refer to drives by drive letters but if you the enter the BIOS setup on some older (often loosely called legacy) machines you may well see A: used in place of floppy and C: in place of hard drive. Such machines could usually only identify one hard drive for booting purposes.
If in doubt about whether the correct partition is being referenced then do remember that the volume label or its size may help in identification. We regularly make partitions into different sizes (even if only slightly different) for this very reason. If still in doubt try another utility or ask for advice before commiting yourself to changes you might regret.
One particular area to be wary about is when using the text mode of NT-Based-Windows installations. The rudimentary operating system that runs these installs (and the recovery console) is a sort of mish-mash of NT and DOS. It can behave to both the user and to the BIOS in unpredictable ways because sometimes it tries to be modern but may revert to being legacy. The Drive Letters it displays are putative rather than being in any way written in stone. Once the system is started the letters represented by setup may or may not still match.
(2) Linux. Devices, including block devices, are represented as files in the /dev folder. Hard drives are normally represented on the IDE interface as hd* or on the scsi interface as sd*, where the * suffix represents a letter of the alphabet. Thus /dev/hda would be the first (suffix=a) enumerated IDE device and /dev/sdc would be the third (suffix=c) SCSI device. This identification has great benefits in defining, fairly unambiguously, which device is which. There are commonly two channels on the IDE interface and each one can have a master and a slave device. The drive enumeration goes hda=(Master-on-#1), hdb=(Slave-on-#1), hdc=(Master-on-#2), hdd=(Slave-on-#2), hde=(Master-on-#3), etc. Channel #3 might be a connection on an additional host controller card. The linux command dmesg should list all devices if you have difficulty knowing which is which. It produces a long list but careful examination of it should clarify the position. Hard drive partition-tables are identified by having a number (starting with 1) suffixed to the device. Thus /dev/hda3 refers to the third partition-table on the first IDE hard drive. NB that the term partition-table and not partition was used deliberately. Most commonly the partition-tables are in the same order as the partitions that they reference and so no misinterpretation occurs. However it is quite possible for the tables to get out of order and, for example, for the third MBR partition-table to reference not the third but the first or second or fourth primary partition.Under linux any extended partition is treated no differently than the other primary partitions when enumerated in this way. An empty primary partition-table simply gets omitted from diplayed lists but has no effect on the actual enumeration of the other primary partition-tables, which retain their values even in the presence of blank lines.
The logical partitions (in an extended partition) are treated in an analagous way and always start with the number 5. Thus /dev/hdc5 refers to the first partition-table entry in the first of a chain and /dev/hdc8 refers to the first partition-table entry in the fourth of a chain of EPBRs (Extended Partition Boot Records) in that particular IDE drive. EPBR sectors look similar to the MBR and precede each logical partition within an extended partition. The chain of EBBRs can be thought of as being a sequence of Parent-Child relationships. As with the primary partitions this daisy chain, though normally in sequence with the actual logical partitions, can get out of order. The first entry of the fourth EPBR's partition-table would normally reference the fourth logical partition but if the daisy-chain is out of sequence it could actually refer to any other logical partition somewhere within the extended partition. In this example (and as seen in the fdisk output in the example below) the fourth EPBR actually references the fifth logical partition and vice versa.
The surest way of deciding which reference relates to which partition (primary or logical) is to look at the Start value (Cylinder or LBA depending on the application) for each partition. Since these are always absolute values it should be straightforward to understand. Run the fdisk -l command (with root or sudo privileges) from a console to see the full list (or else maybe use an application with a GUI such as GParted). The following fdisk -l output example from a SATA drive where the partition-tables are in order and an IDE drive with both the primary partition-table references and the daisy chain of logical extended partition-table references being out of order.
(3) Partition Information Display Examples (one SATA and one IDE drive)
# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 637 5116671 b W95 FAT32
/dev/sda2 638 1529 7164958+ 1b W95 FAT32 (LBA)
/dev/sda3 1530 2421 7164990 b W95 FAT32 (LBA)
/dev/sda4 2422 19457 136841670 f W95 Ext'd (LBA)
/dev/sda5 2422 19457 136841670 c W95 FAT32
Disk /dev/hdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hdc1 129 256 1028160 b W95 FAT32
/dev/hdc2 257 13004 102398310 f W95 Ext'd (LBA)
/dev/hdc3 1 128 1028128+ b W95 FAT32
/dev/hdc4 13005 14593 12763642+ c W95 FAT32 (LBA)
/dev/hdc5 257 1530 10233373+ 7 HPFS/NTFS<
/dev/hdc6 1531 1657 1020096 82 Linux swap / Solaris
/dev/hdc7 1658 10580 71673966 83 Linux
/dev/hdc8 12493 13004 4112608+ b W95 FAT32
/dev/hdc9 10581 12492 15358108+ 83 Linux
Partition table entries are not in disk order
Looking at the Start values of the IDE drive above it should be straightforward enough to see that hdc3 relates to the first partition (Start=Cylinder1), hdc1 to the second (Start=Cylinder129), hdc2 to the third (an extended partition with Start=Cylinder 257) and hdc4 to the four and last primary partition (Start=13005 and End=14593). The first EPBR is referenced by hdc5, then hdc6, then hdc7 - but hdc8 and hdc9 are reversed with Start values of 12493 and 10581 respectively. The physical layout is represented in the following table (copied from the output of GParted). The table is not to scale and the primary partitions are coloured purple. The extended partition /dev/hdc2 (Type0F) - and its equivalent /dev/sda4 (Type0F) in the SATA drive - are not directly visible but contain partitions hdc5, 6, 7, 9 & 8 and sda5 respectively. Because an extended partition is referenced from the MBR's partition-tables it is factually a primary partition - be it all a specialised one. The way that GRUB and the NT-based Windows reference the same partitions are appended as additional lines to the table and will be expanded on later in this page. You should in particular note that the NT-based Windows completely ignore the extended partition itself - it doesn't come into their calculations at all. GRUB starts with partition #0 and NT-Windows (just like native Linux) starts with partition #1.
| /dev/sda1 4.88 GiB Type0B FAT32 | /dev/sda2 6.83 GiB Type1B HiddenFAT32 | /dev/sda3 6.83 GiB Type0B FAT32 | /dev/sda5 130.5 GiB Type0C FAT32 |
| GRUB (hd1, 0) | GRUB (hd1, 1) | GRUB (hd1, 2) | GRUB (hd1, 4) |
| MSDOS (C:) | MSDOS (G:) | MSDOS (E:) | |
| NT rdisk(0) partition(1) | NT rdisk(0) partition(2) | NT rdisk(0) partition(3) | NT rdisk(0) partition(4) |
Table 1. SATA DRIVE (partition tables in order and just one logical partition with white background)
| /dev/hdc3 1004.3MiB Type0B FAT32 | /dev/hdc1 1004.6MiB Type0B FAT32 | /dev/hdc5 9.76GiB Type07 NTFS | /dev/hdc6 996.91MiB Type82 Swap | /dev/hdc7 68.35GiB Type83 Linux | /dev/hdc9 14.65 GiB Type83 Linux | /dev/hdc8 3.92 GiB Type0B FAT32 | /dev/hdc4 12.17 GiB Type0C FAT32X |
| GRUB (hd0, 2) | GRUB (hd0, 0) | GRUB (hd0, 4) | GRUB (hd0, 5) | GRUB (hd0, 6) | GRUB (hd0, 8) | GRUB (hd0, 7) | GRUB (hd0, 3) |
| MSDOS (D:) | MSDOS (H:) | MSDOS (F:) | MSDOS (I:) | ||||
| rdisk(1) partition(2) | rdisk(1) partition(1) | rdisk(1) partition(4) | rdisk(1) partition(5) | rdisk(1) partition(6) | rdisk(1) partition(8) | rdisk(1) partition(7) | rdisk(1) partition(3) |
Table 2. IDE DRIVE (partition-tables out of order and logical partitions out of sequence too)
The 64 bytes inside the MBR that make-up of the four primary partition-tables can be translated into a meaningful and editable display using the PowerQuest PTEdit utility (maintained and freely downloadable in both 16bit DOS and 32bit Windows versions from the Symantec FTP Folder). The output for the IDE drive (/dev/hdc) is displayed in Fig 1 below. [A greater dissection of how the partition-tables' binary code is structured and can be manipulated will be covered in another page currently being put together. The EPBR structures and their "daisy-chain" are also addressed in that page]. Note that there is no Active partition in the examples shown since the systems are being booted from the SATA drive (/dev/sda). An Active (or Boot) partition is designated by an asterix in the Linux-fdisk displays and are given the value 80 in the Boot section of PTEdit . Fdisk shows the partition sizes in Blocks of 1024 bytes and PTEdit in Sectors of 512 bytes.
Even though the SATA is set as the boot drive in the BIOS it is not the first drive enumerated by the BIOS. It is normal for IDE devices to be enumerated before SATA/SCSI/RAID drives and that is also why the GRUB value is hd0 and not hd1 and the Hard Disk shown in PTEdit is Drive1 and not Drive2. In contrast, the rdisk values for the NT-based Windows start with the SATA boot drive even though this is enumerated second by the BIOS. It would be nice to say that every BIOS does things the same way but hard drive enumeration can vary very much from system to system and in multi-drive situations can produce all sorts of unexpected results. Microsoft's own MSKB acknowledges this.
Fig 1.
(4) Windows 2000, XP and 2003 (NT5.0, 5.1 & 5.2). These three NT5 versions of Windows were deliberately left to last because the partition identification is similar, but even less transparent, than under Linux. Once again partitions are identified indirectly via the partition-tables but the rules differ from Linux in the way that (a) blanked or empty partition-tables are treated and (b) how an extended partition and any logical partitions inside it are treated.
Empty partition-tables have lines (visible in PTEdit or with the MBR button in BootIt-NG) that are all zeros. (In fact you can use PTedit to effectively delete a partition by zeroing the line referencing the partition in question). Under Linux the fourth partition-table is always referenced by the suffix 4 as in /dev/hdc4. It is an absolute value. If for some reason the first three partition-tables are blank then this doesn't change the enumeration under Linux. Under NT-Windows however any blanked lines get ignored so that the same reference, with three preceeding blank tables, would be to partition(1). Let us say that there is a primary partition, such as a Dell diagnostic partition, referenced by the first partition-table and that the second partition-table references an installation of Windows XP. Examination of its boot.ini file should show a value of partition(2). If the Dell partition is deleted then Windows should fail to boot because its partition-table reference should now have reduced by one, in this instance to partition(1) since the partition-table's second line is now preceded by a blanked line. There are two ways to resolve that problem. One (generally the easiest) is to edit boot.ini and the other is to move the partition-table values from line2 to line1. If Windows was installed into a logical partition then editing boot.ini is going to be the only effective way to correct things unless a new spurious or real entry is made to replace the original deleted primary partition.
Extended partitions are treated as if they are blanked partition-table lines and are completely ignored by NT-Windows enumeration, with identical effects to the paragraph above. If the first primary partition-table is an extended partition then the next primary partition-table entry becomes referenced by partition(1). What can happen to any logical partitions' enumeration is even more quirky. Under Linux the first referenced logical partition-table is always suffixed with 5 (or 4 with GRUB which starts counting at 0). Under NT-Windows the first logical partition-table is enumerated with the number just one greater than the number of existing (excluding the extended partition) primary partitions. Thus if there is only one primary partition the first logical will be partition(2). If another primary partition gets created anywhere then the first logical becomes partition(3) and with a third primary (the maximum when an extended partition has been created) the first logical becomes partition(4). Thus if an NT-Windows boot partition is a logical partition its boot.ini will become invalid whenever primary partitions are created or deleted.
Assignments (by Drive Letter) under NT-based Windows
The numeric partition references in boot.ini are mainly of relevance to the boot processes. Once any NT-Windows has loaded for the first time the partitions are assigned Drive Letters. These initial assignments are automatic and, as with the DOS-based Windows, follow their own initial assignment rules. See Microsoft's How Windows 2000 Assigns, Reserves, and Stores Drive Letters (it is essentially the same for the other NT-based versions of Windows) for details regarding both Basic and Dynamic Disks. Note especially that once initially assigned, these values are retained (they are static or persistent unlike the dynamic nature of drive letter assignments under the DOS-based versions) for all fixed disks. Even with removable drives the system will try to retain the settings unless some other device has grabbed that particular letter in the meantime.
The
identifications and the mappings of the partitions are stored
in the registry at
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. The 12-byte volume id breaks
down into two hexadecimal numbers. The first four bytes are the same as
the disk signature in the MBR. The last eight bytes are (in little
endian format) the offset to the start of the partition in bytes. To
convert to decimal sectors this number first needs the eight bytes
reversed (for endiandness reasons), then converted to decimal and then divided by 512. The
breakdown of the value for the H: drive in Fig 1 and the
associated examples above follows:-
The registry's MountedDevices values were: \DosDevice\H: REG_BINARY b7 a9 1a ea 00 00 c1 3e 00 00 00 00
- The Disk Signature in the MBR would match the first four bytes: b7 a9 1a ea
- The next eight bytes have their order reversed thus becoming: 00 00 00 00 3e c1 00 00
- Without the leading zeros this looks neater as the hex number 3e c1 00 00
- The hex number 3ec10000 converts to the decimal number 1052835840 (the relevant offset in bytes)
- 1052835840 divided by 512 gives 2056320 as the "Sectors Before" value for /dev/hdc1/ (hdc1 being the first partition table - itself referencing the second physical partition in this instance).
This means that when detached hardware is re-attached that it is possible for it to be immediately re-recognised and - as long as it creates no conflicts with the previously loaded system's assignments - to have the original drive letters re-assigned to the partitions in question. One "trick" in this area is to use a drive letter way up the alphabet for removable drives (which makes that letter unlikely to get used by other drives) and thus to be re-assigned the same drive letter when re-attached. Removable drives including floppies and CDdrives have a longer more elaborate, but still unique, volume id.
The DiskManagement console can (with the main exceptions of system and boot partitions) re-assign drive letters to drives. It can also remove them altogether and on NTFS formatted partitions can also mount the partitions in empty folders in a manner analagous to mounting partitions under Linux.
The converse is equally true. That is to say that if either the disk signature is changed or if partitions are manipulated with partitioning tools then the logical disk manager will need to re-assign letters anew (the actual letters may be retained or changed depending on "the rules") because the algorithms no longer match up with what is held in its registry database. So this can mean two main things: firstly that drive letters get changed and secondly that the drive as a whole is considered to be new hardware. When the latter happens (always after a disk signature is changed) you will be prompted to reboot the system. One of the reasons for using fixmbr from the RecoveryConsole instead of the MSDOS fdisk /mbr equivalent is that the former doesn't and the latter does create a new disk signature. Use fdisk /mbr with caution on these systems since it can cause the system to fail to boot if the remapped drive letters cant find what it requires to start up. It can also be used to force the OS to reassign all the drive letters to their default assignments (as can deleting the whole MountedDevices key). These measures can correct but can also create certain problems and should only be done if you really understand what is going on and the possible consequences including the need to re-assign drive letters appropriately. A back-up of the MBR can be invaluable if the system fails to reboot after fdisk /mbr.
A particular note of caution is necessary when hard drives are cloned. Bear in mind that at that moment in time both drives will have the same registry entries but different disk signatures. Even if the disk signatures are initially the same on the clones, then if they are booted up simultaneously together, one or both will be given a new disk signature with all sorts of potentially horrible consequences. Don't let both drives "see each other from Windows" until the newly cloned drive has bee booted-up on its own and rebooted on its own to allow its registry to re-assign drive letters and to set these entries in its registry. If this is done then the original can then be added back to the system and the new clone will give the orignal drive new drive letter assignments.
Notes on Windows NT4 and NT6 (Vista)
These pre and post NT5 versions of Windows are pretty similar when it comes to partition-referencing. Major related differences do however occur because NT4 cannot deal with FAT32 and must utilise FAT16 or NTFS partitions.
Vista's major difference is not so much with enumeration and letter-assignments than with a new boot process that supercedes the use of the boot.ini file used by all the earlier NT-based versions of Windows. Modifying Vista's boot menu is therefor no longer a matter of simply editing a text file. The Vista boot menu is edited programatically and this can be done using BCDEdit from the command line or with the very useful free download (which will also run under Windows XP) called VistaBootPro.
Notes on System -v- Boot Partitions (Volumes)
Microsoft, unlike others, has helped to make this area more confusing than it need be by calling the active partition the System partition. It calls the partition on which the Windows folder is placed the Boot partition. Just as obtusely the Windows folder itself is then regularly referred to as the "System" folder. On single partition systems the System and Boot partitions must be one and the same but in multi-partition/multi-booting environments it can be important to differentiate which is which. It is most common for Windows to be loaded via a hard drive primary partition marked as active and that contains certain boot files. The boot processes for most NT-Windows and Linux Distros can alternatively be initiated from a boot floppy diskette and thus "leap-frog" or otherwise avoid using the normal process that involves the bootstrap code on the active (system) partition. Such a diskette may contain specific boot files but, most critically, must have an appropriate boot sector.
It is commonplace to start up Linux, by-passing the active partition and by booting to a logical partition. With some tweaks to that logical partition's boot sector this can also be arranged for Windows. In both instances this method is normally begun either from a floppy or from a boot manager on the MBR. See Goodells Multibooting pages for a good primer on such techniques. It maybe simplistic to say that the boot processes go FROM one place and TO another (eg from a System partition to a Boot partition) but that is exactly what goes on. Just maybe pause for though and consider the processes going on and not ever simply assume that "the boot partition" is anything written in stone.
Referencing and the Extended Partition
PTEdit is probably the easiest tool with which to examine an extended partition. On starting PTEdit just one row in the MBR's partition-table can be of Type 0F (ExtendedX). This could be a partition with say "Sectors Before" = 4112640. Remember this value (always write down the equivalent value in your own system) because this value gets used again and again. This value shows that the first EPBR starts as that LBA offset, viz: 4112640 in the IDE drive referred to earlier and represented in Table 3. Since the offsets start counting with 0 this is the 4112641st sector! Next place the cursor in the row with type 0F and click on the GoTo EPBR button (effectively to the next child record) to take you to the first EPBR which is also the very start of the Extended (the ExtendedX) partition.
When in the first EPBR, under the chosen Hard Disk drop-down menu, there should be a reference along the lines of: "Partition Table at sector 4112640 (cyl 256, head 0, sector 1)". The first row in this partition-table is a reference to the current EPBR's own logical partition. It could be of any Type and its "Sectors Before" value is almost invariably 63 being the offset jump to the PBS of the current EPBR. Thus this particular PBS should be found at sector 4112640 + 63 = 4112703.
Table 3.
If the second row of an EPBR is all zeros then that is the end of the daisy-chain and the Goto EPBR button should be greyed. If the second row has values then it will be of Type 05 (for an extended partition boot record) and which might have a "Sectors Before" value of say 20466810. This "Sectors Before" value is referenced from the start of the very first extended partition boot record, which is also the very start of the whole extended partition and which we know already is at sector 4112640. Thus the next EPBR should be found at 4112640 + 20466810 = 24579450. This can be confirmed by using the GoTo EBPB button again. It should thus read Partition Table at sector 24579450 (cy l530, head 0, sector 1) and once again have one or two rows of values in its partition-table record.
And so on and so on until the end of the daisy chain is reached. Just note, in particular, that the first row of each partition table gets referenced from its own EPBR but the second row is referenced from the start of the first EPBR - that is from the very start of the extended partition. This is a common cause of confusion.
Footnotes
1. The DOS-based OSes include the various versions of DOS itself and of all the MS Windows versions up to Windows Millenium. These are only ever installed on FAT partitions and can only ever natively "see" what is on FAT partitions. Other formats become invisible. These operating systems assign drive letters to partitions dynamically such that changing, moving, adding and removing drives/partitions can change their Drive Letters.
2. The NT-based OSes (Microsoft's New Technology Operating Systems) started with Windows NT and also include Windows 2000 (which despite its name is not Milennium), XP, 2003 Server, PE and Vista. These systems can use both FAT and NTFS formatted partitions and, even if installed on FAT, can properly "see" other NTFS partitions. Once Drive Letters have been assigned to partitions they remain (with some exceptions when there are later conflicts) assigned as long as the partition's size and its partition table reference and its hard drive signature remain unchanged. Under Windows Vista changing the disk signature (say by running fdisk /mbr) can not only cause the Drive Letters to be re-assigned but also to prevent booting along with a winloader.exe warning message.
