Talk:Extended boot record

message: 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)
replies: text: 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)
thread_title:  EMBR vs EBR 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Values 

message: 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)
thread_title:  Extended Partitions: ''Chained,'' ''Nested,'' or both?

message: [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)
thread_title:  EBR ''Second entry'' comments and diagrams were wrong! 

message: 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)
thread_title:  ''Corrected'' images; need real examples! 

message: 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)
replies: text: 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)

text: 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)
replies: text:  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)
thread_title:  ''Nested'' partitions might exist... 

message: 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)
thread_title:  The graphical example 

message: In russian version of this article I have ported example's table from png to wiki markup. It would be easy for someone to port it from russian to english (you do already have english png) Yanpas (talk) 13:11, 18 January 2016 (UTC)
thread_title:  Table 

message: In the Extended boot record#EBR structure and values section, the article states the following:
The CHS addresses of a partition are hard to interpret without knowledge of the (virtual) disk geometry, because CHS to LBA translations are based on the number of heads and the number of sectors per track. However, the given LBA start address and the given partition size in sectors permit to calculate a disk geometry matching the given CHS addresses where that is at all possible.
I don't dispute that you can probably calculate some combination of cylinders, sectors per track, and number of heads that will equate the number of sectors between start and end CHS to the LBA length.  However, there may be several such solutions, and there is no definitive way (that I know of) to ensure you've arrived at the correct combination without knowledge of the underlying geometry.
Maybe this is why it says "permit to calculate a disk geometry" and not "the disk geometry"?  If that is the intent, I question the value of this statement.  After all, it could be potentially disastrous to solve for a qualifying (but ultimately incorrect) geometry, if that calculation is to be used for any I/O operation on the disk.
Eleganthack (talk) 05:18, 29 July 2016 (UTC)
replies: text: I am not sure of the original motivation for wording it that way, but it does nicely cover implementation trivia of drives since 2000 or so which vary the number of sectors depending on what part of the platter they are written.  —EncMstr (talk) 16:28, 29 July 2016 (UTC)
thread_title:  Converting between CHS and LBA 

message: Hello fellow Wikipedians,
I have just modified one external link on Extended boot record. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20110728081430/http://www.t10.org/t13/project/d1321r3-ATA-ATAPI-5.pdf to http://www.t10.org/t13/project/d1321r3-ATA-ATAPI-5.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 11:39, 26 September 2017 (UTC)
thread_title:  External links modified