Talk:Extended boot record

EMBR vs EBR

This information is incorrect. It's a common error but the correct term is EBR (Extended Boot Record). Search the MS KB for EBR (they designed the layout of the extended partition). The EMBR is a specification created by TeraByte Unlimited (http://www.terabyteunlimited.com/specs/embr2.pdf) which was the template design for the next generation of PC's using EFI.

Sounds good to me; EBR is also more logical, since these aren't master records. I have changed the naming. Too bad I can't update the EMBRs in the graphics. The text also said the EBR is the extended partition, so I fixed that too. Bryan Henderson 17:56, 3 December 2006 (UTC)

Though I'm stating this after the fact, just wanted to say I def. agree since I had to alter some of my own statements years ago when I realized that my use of EMBR was incorrect too. So I'm doing what I can to fix any occurrence of the term here. Daniel B. Sedory 09:22, 15 April 2007 (UTC)

Values

In the values sections there is a note...

Note : Starting sector + Number of sectors equals the size of the extended partition

I think it should read...

Note : Number of sectors equals the size of the extended partition

I'm fairly certain the number of sectors by itself is the size. The starting address is simply an offset.

Tekemperor 04:02, 10 March 2007 (UTC)

Tekemperor, I'll be looking into this in deatil as soon as I can... we need to examine this with some real-life examples (I'll use my own, multi-partitioned hard disk) so everyone can clearly see what the values represent and how they're used. Daniel B. Sedory 10:51, 11 April 2007 (UTC)

After finally taking the necessary time to examine this whole article and your concern, I've concluded that this particular note was likely misplaced and I'm removing it. It certainly doesn't apply to the second entry of an EBR; but neither do the existing notes! (Read the next topic here.) Daniel B. Sedory 09:07, 17 April 2007 (UTC)

Extended Partitions: Chained, Nested, or both?

First, this title is a newer entry to the page than the 'subsection' which follows! But in hindsight, I felt the discussion needed a slightly better format than just adding a new comment far below; especially since I recently came across the idea that nested extended partitions might exist on a functioning system if they were purposely created (manually) by someone with the knowledge to do so, or possibly by some partitioning tool programmed by someone who didn't follow the actual method used by Microsoft/IBM for MS-DOS 3.3 and following (which all my tests so far, prove to use only the chaining method). I will probably add at least a small note about nesting possibly existing on some systems, but sure wish I could find some specific research on this topic. Doing exhaustive testing of EBRs with every OS I can obtain access to, will take much time I don't have. Daniel B. Sedory 10:39, 1 May 2007 (UTC)

EBR Second entry comments and diagrams were wrong!

[At least according to all the OSs (some listed below) that I could test at the time I started this discussion note.]

Having done a thorough analysis of EBR data acquired from many different hard disks, I can say without a doubt the Number of Sectors item in the second entry of each extended partition table does not, and as a rule was never meant to, include the remainder of the entire extended partition! Only under some conditions, such as an extended partition that contains only two logical partitions, might such an observation coincidentally be made. Thus, I'll be working on some new general rules for this article, and new diagrams (I have already completed them and edited the article; see below) concerning all second entries that will correctly show that the Number of Sectors item (in second entry) enumerates ONLY the size of the next logical partition; not something that runs to the end of the extended partition in every case.

The following sample data, taken DIRECTLY from hexadecimal dumps of two different hard disks (an 80GB and a 200GB) and converted to decimal numbers, clearly illustrates why my statements above are true. In this first table (from an 80GB drive), the Extended Partition was the 4th entry in the MBR's Partition Table, it begins at LBA 41,287,050 and ends at LBA 156,296,384; thus, the reason it's size entry is: 115,009,335 sectors. Here are the Starting sector offsets and Number of sectors items for both the first (1SS, 1NS) and second (2SS, 2NS) entries in each EBR of this disk:

EBR-1                                 (LBA = 41,287,050)
1SS = 63           1NS = 40,644,387
2SS = 40,644,450   2NS = 30,812,670

EBR-2                                 (LBA = 81,931,500)
1SS = 63           1NS = 30,812,607
2SS = 71,457,120   2NS = 530,145

EBR-3                                 (LBA = 112,744,170)
1SS = 63           1NS = 530,082
2SS = 71,987,265   2NS = 9,622,935

EBR-4                                 (LBA = 113,274,315)
1SS = 63           1NS = 9,622,872
2SS = 81,610,200   2NS = 33,399,135

EBR-5                                 (LBA = 122,897,250)
1SS = 63           1NS = 33,399,072
2SS = 0            2NS = 0

Last LBA sector of extended partition = 156,296,384

Look very carefully at all of the "2NS" entries. They clearly do NOT show a decreasing amount of space as you near the end of the extended partition! They are merely the size of each logical partition that follows their own. Note: You can also clearly see that each 2NS entry of each previous EBR minus the 1SS entry of its next EBR (always 63 here) equals the 1NS entry of that EBR. For example, (the 2NS entry of EBR-4) - 63 = (1NS entry of EBR-5) = 33,399,135 - 63 = 33,399,072.

Again, here's some data from a 200 GB drive (with its extended partition as the 2nd entry in the MBR) showing the same patterns in its EBR entries:

EBR-1                                  (LBA =  40,965,750)
1SS = 63            1NS = 61,432,497
2SS = 61,432,560    2NS = 10,233,405

EBR-2                                  (LBA = 102,398,310)
1SS = 63            1NS = 10,233,342
2SS = 71,665,965    2NS = 16,386,300

EBR-3                                  (LBA = 112,631,715)
1SS = 63            1NS = 16,386,237
2SS = 88,052,265    2NS = 14,747,670

EBR-4                                  (LBA = 129,018,015)
1SS = 63            1NS = 14,747,607
2SS = 102,799,935   2NS = 140,906,115

EBR-5                                  (LBA = 143,765,685)
1SS = 63            1NS = 140,906,052
2SS = 0             2NS = 0

Last LBA sector of extended partition = 284,671,799

Final comment: I believe whomever initially wrote the notes and/or diagrams for this article may have been misled by the oft-repeated idea of each logical partition being nested within the previous one. Although that logically (no pun intended) seems to make sense, perhaps the designers of this method foresaw doing so would cause a lot of headaches for anyone desiring to resize a logical drive within an extended partition?

I have reworded the previous 'rules' for understanding and computing the values in the EBR partition tables. At the same time, I've corrected the error in Diagram 2 by uploading a new version of its image file. Just to be sure the new Windows XP drives are not using some new table algorithms, I partitioned a small 200+ MB sized drive under IBM PC DOS 5.02 and the same patterns emerged; as you can see in the following data. Anyone can create and test old drives like this using BOCHS or some other emulator. Here's the pertinent data from extended partition tables:

Daniel B. Sedory 02:21, 18 April 2007 (UTC)

EBR-1                       (LBA  61,488) 20.1 MiB
1  = 63        1  = 41,265
2  = 41,328    2  = 21,168

EBR-2                       (LBA 102,816) 10.3 MiB
1  = 63        1  = 21,105
2  = 62,496    2  = 61,488

EBR-3                       (LBA 123,984) 30.0 MiB
1  = 63        1  = 61,425
2  = 123,984   2  = 31,248

EBR-4                       (LBA 185,472) 15.2 MiB
1  = 63        1  = 31,185
2  = 155,232   2  = 90,720

EBR-5                       (LBA 216,720) 44.3 MiB
1  = 63        1  = 90,657
2  = 0         2  = 0

Daniel B. Sedory 02:21, 18 April 2007 (UTC)

And, of course, if anyone has raw data from any hard disk extended partition that does NOT show the same patterns as above, I'd definitely want to see that data, so we could add some note about it in the future! Daniel B. Sedory 10:42, 17 April 2007 (UTC)

Corrected images; need real examples!

The last two images have been corrected, so the 'caution note' concerning them has been removed. But since these images were initially contrived under erroneous assumptions, you can easily see why new images could be more appropriate. What's really lacking now, though, are some REAL examples. So, when I can, I'll try creating a table from some of the data I gathered about Extended partitions, perhaps from one of the examples I listed above; with more details in the article, of course. Daniel B. Sedory 12:01, 21 April 2007 (UTC)

Nested partitions might exist...

But I've yet to find one in any OS tested so far. According to the quote below, from Andries Brouwer's 1995 source code for sfdisk, he considered nesting one of two "common" structures for extended partitions, but when I recently asked him (e-mail) what partition tool or OS formed nested EBRs, he said he couldn't remember. So my contention is still: A possibility, yes, but I certainly wouldn't call nesting "common" (i.e., for the majority of disks on user's computers for quite some time):

/* There are two common ways to structure extended partitions:
  as nested boxes, and as a chain. Sometimes the partitions
  must be given in order. Sometimes all logical partitions
  must lie inside the outermost extended partition.
NESTED: every partition is contained in the surrounding partitions
  and is disjoint from all others.
CHAINED: every data partition is contained in the surrounding partitions
  and disjoint from all others, but extended partitions may lie outside
  (insofar as allowed by all_logicals_inside_outermost_extended).
ONESECTOR: all data partitions are mutually disjoint; extended partitions
  each use one sector only (except perhaps for the outermost one).  */

Words in box above quoted from 'sfdisk.c' at: http://fresh.t-systems-sfr.com/linux/src/util-linux-2.13-pre7.tar.gz:b/util-linux-2.13-pre7/fdisk/sfdisk.c

Another concern which Andries told me is that the OSs which he'd tested didn't care what values were in the Number of Sectors entries, only the location of the next EBR. This is easy enough to test for my present OSs, and if any partitions are 'lost' I can recover them manually myself. So I'll try leaving a comment on this aspect in the near future. Daniel B. Sedory 10:39, 1 May 2007 (UTC)

I've finished testing a number of DOS (including MS-DOS 3.30), Linux and Windows installations, and just as Andries had found, none of these OSs care one bit what value is in the Number of Sectors fields for any of the second entries in the EBR tables (with the exception that Linux won't abide having a 'zero' there, so any value from 1 all the way to 0xFFFFFFFF is acceptable), because they simply don't use it! This means whether or not nesting (vs. chaining) even existed in the mind of some partition tool's programmer (though I haven't found one that has yet), as far as these particular OSs are concerned, it's just your imagination; they treat 'em all the same way: independent partitions, linked together by a chain of EBR table data. Daniel B. Sedory 15:18, 10 May 2007 (UTC)

GParted seems to have created nested partitions for me. The layout I've got has the logical partions in reverse order (hda9, hda8, hda7, hda6, hda5) within the extended partition, and all the EBRs are at the beginning of the outer extended partition. I'm not sure how I got to this point; I think I started with a small extended partition at the end of the disk, and over time removed or reduced my primary partitions, resized the extended partition "to the left", and created additional logical partitions in the newly available space. Steved424 (talk) 21:01, 23 January 2008 (UTC)

Steve, I'd like to see the raw bytes for the structure if possible; if you go to This web site and find the 'feedback' page there will be an e-mail address you can write to me at (don't want to get SPAMMED by printing it here; please use "TSR:" in the subject line). Of course, your comments above show this isn't how GParted would normally create an Extended partition. If I'm reading your comments correctly, GParted may not check anything before creating a new extended partition. Daniel B. Sedory (talk) 22:23, 24 January 2008 (UTC)

Question about Diagram 2 in the article

On the topic: I checked my disk, and I got the following:

MBR
#1: +32, 78135264
EBR.1 (@0+32)
#1: +32, 41943008
#2: +41943008, 16787456
EBR.2 (@32+41943008=41943040)
#1: +32, 16787424
#2: +58730464, 2103296
EBR.3 (@32+58730464=58730496, [*1] but not at 41943040+58730464)
#1: +32, 2103264
#2: +60838123, 17285940
EBR.4 (@32+60838123=60838155, [*2] but not at 58730496+2103264=60833760)
#1: +63, 17285877
#2: +0, 0

• 2 seems to indicate that there can be slack space between the end of the partition pointed to by this EBR and next EBR (in this case, it's blocks between 60833760 and 60838155, or 4395 blocks. In other words, #2.SS is checked (though #2.NS is not).
• 1 seems to indicate that the location of next EBR is obtained from this EBR.#2.SS, but that this offset is relative to the very first EBR in the chain, not this EBR. The EBR chain drawing would be wrong, then.

I'll try to check sfdisk.c Jmgonzalez 14:05, 30 May 2007 (UTC)

There could be several explanations for what Jmgonzalez is seeing on this hard disk, but first, we need to know what tool(s) were used to create the partitions, and equally important, we need to know how the information above was obtained! For all the hard disks I've examined, I used a disk editor to view raw hex data on all the sectors; none of it was interpreted first for me by some utility program! Since it appears there are a number of 31-sector 'unused areas' but then a 62-sector 'unused area' at the end, that might indicate a different tool was used for that partition. Gaps, just as the two examples in the article show, quite naturally occur if an original logical partition between two others, or the first or last one within the extended partition have been deleted... which could easily be the case here. I'm going to contact Jmgonzalez for more information before providing any further conclusions here. Daniel B. Sedory 08:07, 31 May 2007 (UTC)

Answering to your questions, I use dd and xxd. Moreover, my disk is a 40GB USB disk. I don't know how it was formatted: From my environment, I assume fdisk on Linux (the last logical partition may well have been formatted using a different tool)

My point, though, is that the offsets in diagram 2 seem to be wrong (let's limit the discussion to offsets, as the existence of gaps means they are the method to walk a partition table). In all the cases in this discussion (including my disk, which I know works fine in linux), the offsets of the second entry in the EBR must be applied to the location of the very first EBR in the chain. In the first disk in the discussion, we have the following:

EBR-2                                 (LBA = 81,931,500)
1SS = 63           1NS = 30,812,607
2SS = 71,457,120   2NS = 530,145

EBR-3                                 (LBA = 112,744,170)
1SS = 63           1NS = 530,082
2SS = 71,987,265   2NS = 9,622,935

In this example, if Diagram 2 were right, the next EBR for EBR-2 should be located at EBR-2.LBA + EBR-2.2SS, approximately at sector 153M. Instead, we know that EBR-3 is located around sector 112M, which is exactly ERB-1.LBA + EBR-2.2SS. Same thing happens in all the examples.

This is extremely weird: the two offsets in an EBR refer to different starting points (1SS to the location of the local EBR, 2SS to the location of the first EBR in the chain).

Jmgonzalez 14:37, 31 May 2007 (UTC)

• Jmgonzalez: OK, I had some difficulty seeing what your comments were actually about at first. Now I know why you're concerned about the first entry in Diagram 2. The key to understanding that diagram is the phrase: point to; in both diagrams, the first value (Starting Sector) points to an EBR, rather than enumerating a partition's size. It's only a coincidence that the arrow in Diagram 1 can also be interpreted as giving the value we use to do that pointing, since it merely crosses over the "unused area" (usually 62 sectors); whereas the arrow in Diagram 2 doesn't help in computing that entry's SS value! Can you see a way we could display both how a previous EBR points to the next one and how its value is computed without overly complicating things? This is why we spelled out the rules above the diagrams, specifically for the 2nd entry's SS value: "or: Starting Sector = LBA address of next EBR minus LBA address of extended partition's first EBR." I wouldn't call this "extremely weird," because it gives us solid references (using an LBA count also would have done so, but the original DOS programmers chose first sector of the extended partition instead) in which one logical partition isn't dependent upon any 'possibly changing values' derived from all the others (like after a partition is deleted) for its location. Daniel B. Sedory 09:00, 1 June 2007 (UTC)

Daniel, I think we agree on how this works. But, when you say a value "points to" something, that value either is an absolute value (the LBA itself) or is an offset from another value. It seems clear from our discussion that the SS value in entry #2 is an offset. In this case, you need to specify where the offset is relative to.

So, for drawing 2, the SS field must reflect that the offset of the next EBR refers to the very first EBR in the chain. While this is mentioned in the rules above the diagram, the drawing seems to imply that the offset must be calculated from the local EBR.

A better solution for Drawing 2 could be as the following image: [1]. Let me know if you have any problems seeing it.

Jmgonzalez 10:49, 1 June 2007 (UTC)

Jmgonzalez: Sorry, but the diagram you linked to is not clear enough on my screen to see all the connecting lines; I believe I understand the general idea you're trying to get across, but don't want to comment on your diagram based on what would only be some assumptions.

Concerning what you did write above though, I think you're still missing my point: That the first arrows (on left side in both Diagrams 1 and 2) are merely visual pointers showing to which partition (in 1) and EBR sector (in 2) they point to. Neither of them are meant to describe in any way HOW their offset values are calculated! Both of them were only meant to represent the idea of an operating system or utility using their particular entry to locate its partition (1st entry), or the next EBR (2nd entry); they are not meant to show how these values are computed. The SECOND SET of arrows, by nature of the fact they indicate a RANGE of many sectors (using two arrowheads for each entry), do imply where their values come from.

In order to visually show BOTH how the offsets are calculated for the Starting Sector values AND what sectors they point to in a single diagram, you'd need something like two different types of arrowheads (which the present diagrams lack; I didn't create them, only edited them) so people wouldn't confuse the pointer part of the first entry with a value part connected to the same arrow! In my mind that's really getting too complex (as I said earlier). So, if visualizing both ideas is something the article really needs, I'd propose having another set of two more diagrams: The first set would only show the partition and next EBR sector that the entries point to, and another set related to how those values are computed... which still seems more complex than necessary when the TEXT already clearly describes how they can be computed. We could also use some diagrams showing how deleted partitions within an extended partition affect these pointers. Daniel B. Sedory 08:19, 2 June 2007 (UTC)

Daniel, please try the following image: [2]

On the discussion, I think we both agree how this works. I also think that the drawing is misleading, as the value is an offset, and the way it's represented would seem to imply that it's an offset from the current EBR. But, maybe it is just me who find it so misleading. Please let me know whether you find the above image more clear. Jmgonzalez 17:00, 4 June 2007 (UTC)

The new image is quite clear. Unfortunately, what it displays is incorrect. The first offset you show would be true for Diagram 1; not 2, and the other two Starting Sector parts are just plain wrong (they need to show the offset to the next EBR sector in the chain, not to their own partition; as they do in Diagram 1). The Number of Sectors arrows, being the same as the present Diagram 2, are shown correctly. I will add another diagram to the article in the near future which should make these values visually more understandable. Daniel B. Sedory 20:11, 4 June 2007 (UTC)

Oops, you're right. I fixed the drawing (please check [3]). I think now it's clearer what every field means.

Now, I have the original svg used to obtain the png. If you're interested in using it as a starting point to fix diagram 2, please let me know and I'll publish it. Jmgonzalez 12:39, 5 June 2007 (UTC)

Just wanted to let you know I haven't forgotten about this, but have had finding a job and other personal interests such as my own web pages necessarily take priority. Apart from the fact your diagram has an 'undefined' white space between each partition; only a minor issue, but one that would have to be addressed before adding it to the article, the major problem, IMO, is that it doesn't show previous EBRs as pointing to the next EBR in the chain, only a range of sectors! Thus, it's lost the emphasis in the present diagram for the first part of the second entry. I still need to consider some alternatives (different diagram or MORE than one diagram, etc.), but finding work must take precedence. Daniel B. Sedory 07:57, 11 June 2007 (UTC)

The graphical example

In the example the next partition is more closly connected to the next EBR then to its own (due to separation by gray strip). Could the red borders betwean partitions and next EBR be added? Uzytkownik (talk) 20:08, 29 November 2008 (UTC)

EBR table entry structure

struct EBR_entry{
char ? ;
char ? ;
char FS_ID ;
char ? ;
char ? ;
char ? ;
int  offset_to_next_ebr ;
int  size_next_partition ;
char ?;
char ?;
};