0

I have an MBR drive with a Windows XP installation on partition 2, which boots using a boot.ini entry that specifies patition(2). The partition table initially looks like this:

1. Windows recovery partition
2. Windows XP
3. Linux
4. Linux

I then remove partition #1 and replace it with an extended partition, which results in this table:

1. Extended partition
2. Windows XP
3. Linux
4. Linux

Now Windows XP won't boot, complaining of a missing hal.dll. The partition number in boot.ini hasn't changed, and the partition number in the MBR partition table hasn't changed. Nevertheless, when I change Windows XP's boot entry in boot.ini from partition(2) to partition(1) Windows XP starts with no problems again. I would like to know why, exactly.

I'm reading https://neosmart.net/wiki/rebuilding-boot-ini-file/ which has this to say about boot.ini partition numbering:

partition(y): The number of the partition on the drive rdisk(x). partition(y) starts counting from 1, so the first partition is partition(1), the second is partition(2), etc. partition(y) counts primary partitions first then counts logical partitions. The extended partition (the “container” for logical partitions) itself isn’t counted, though. These numbers are taken from the Partition Table in the Master Boot Record, which will generally be the order in which they were created, which will not necessarily be the same as the order in which they appear on the disk

Is this really true? Because from my perspective I seem to have changed the partition numbers simply by replacing partition entry 1 in the MBR.

For the record, parted tells me that the Windows XP partition is indeed number 2, and fdisk tells me it's /dev/sda2 (though I'm not entirely prepared to trust device numbering schemes to correspond exactly to MBR partition numbers). Even if the operation of removing and replacing partition 1 did result in rewriting the entire MBR partition table, surely this output should confirm that the Windows partition did in fact end up in the right place anyway?

Am I missing something in my understanding here?

Andreas
  • 674
  • 3
  • 11
  • 33

2 Answers2

2

It seems to me that your post contains all the elements for understanding the answer, although there can be more than one rule of counting that may apply (as mentioned in your comment).

If the order of creation of the partition is the determinant in allocating numbers, then the reason is that you had deleted partition #1, therefore making #2 into the new #1.

The new Extended partition partition that you created is then following all the other entries in its order of creation, so is presumable now a higher number (perhaps #4 as it's now the last one).

To clarify, the quote you gave mentioned creation date, when it probably really meant partition order. This would be the same if deleted partition entries in the table are not reused after deletion.

The partition-number allocation algorithm seems to be very simple-minded : Windows allocates partition numbers by their order in the partition table, and not by their position. So partition #1 may be found in table entry 2, if entry number 1 is empty or a type that the BIOS will ignore (I doubt that such types exist).

harrymc
  • 498,455
1

Keep in mind the entire "ARC path" facility in boot.ini is not native to BIOS/MBR systems. It comes from ARC-type firmware that was present on DEC Alpha systems – the original platform that Windows NT was built for, and the predecesor of today's EFI-type firmware – and the entirety of Windows' NTLDR (and boot.ini) is just an emulation of what would normally be provided by firmware on more advanced platforms.

Therefore, when the Windows bootloader interprets ARC paths on BIOS systems, it tries to hide MBR-specific quirks such as "extended partitions" and present a generic, flattened view of the volumes within (for lack of a better term). Since an extended partition doesn't directly represent something that would hold data, it is ignored here.

I have a horrible feeling that my answer lies in the quoted sentence "The extended partition (the “container” for logical partitions) itself isn’t counted, though"...

Conveniently, the leaked source code of Windows XP is still available on Microsoft's GitHub. Digging through it, the partition number from the ARC path is ultimately handled by HardDiskPartitionOpen(), which has code to deliberately skip MBR partition slots from the count if they are either a) empty (type 0x00), b) EFI protective partition (0xEE), or c) IsContainerPartition() (0x05 or 0x0F). In other words, it does not count partition slots that have other purposes than directly holding data.

(Additionally, the position of the "extended" partition doesn't matter; it's always processed after the basic MBR slots have been processed.)

grawity
  • 501,077