Talk:Master boot record/Archive 1

Archive 1

Windows 2K+ serial number

I put this back in. Even though I'm an OSS fan myself, the majority of hard drives in use today have this serial number; people who have one may need to know what it is. — Preceding unsigned comment added by Dogcow (talk • contribs) 23:42, 30 November 2006

I'm inclined to Rototill...

As no other OS besides those associated with i386 (or variant) PCs uses the term MBR, I'm inclined to rewrite things as such. Unfortunately, partition table redirects here currently - and MBR and partition table are most definitely not synonymous. Any comments from y'all? --moof 22:42, 30 November 2006 (UTC)

Repetitive Sentences

Currently the first entry under References includes two sentences with similar meanings, one right after the other:

The status fields in the extended partition table records are used by boot manager programs to determine which partitions are bootable. (In IBM nomenclature, such partitions are described as bootable.)

I propose that the section in parentheses be deleted unless someone with more knowledge of this topic can give these two more distinct meanings. --Jarsyl 05:41, 1 February 2007 (UTC)

After further study of the (OS/2) "IBM Boot magager" which convinced me it had no place in our first table describing the main sections of the MBR (where references to an altered MBR for "IBM Extensions," as they were being callled, seem far from appropriate; see below), I will definitely be altering this note concerning the Partition Table layout. Daniel B. Sedory 21:21, 8 April 2007 (UTC)

Misplaced Content?

This text from the middle of the Backing up the MBR section seems inappropriate for this page, or at least for this section. I could correct the grammar but this would make it stand out less. Would anyone care to second it being deleted?

If you are backing up a hard drive, also known as ghosting, and are having issues with new hard drive saying the paging file is not found, then running 'fdisk /fixmbr', (done from a bootable floppy disk since cannot log into Windows), will most likely solve your problems.

--Jarsyl 05:50, 1 February 2007 (UTC)

Jarsyl, yes, I second your opinion and have removed the paragraph as being inappropriate, because it really had nothing to do with the MBR sector. Daniel B. Sedory 07:14, 23 March 2007 (UTC)

Relocation of MBR

According to [present version], the MBR code usually relocates itself elsewhere in memory, and -- often at 0x7A00. I do not know which one code relocates to 7A00H, but the most used by a far margin is the code originally written by David Litton at IBM, and all its derivatives including the ones from Microsoft, and they relocate to 00600H. Many clones also chose the same address. So I would like to know which evidence led to the present text. Antoinel 12:41, 19 February 2007 (UTC)

Antoinel, I agree, and changed the page from often at 0x7A00 to "often at 0x0600 (for Microsoft code)." The only reference I could find to 0x7A00 was in a single personal code example at a forum, but I have no idea where BruceEwing (who added that material according to the edit history) got his information from. Daniel B. Sedory 03:59, 22 March 2007 (UTC)

I received a message why I had changed the lowest accessible address from 0x500 to 0x600. 0x500 is well into the region used by BIOS; in particular, address 0x500 is used by the Print Screen function in the BIOS. Certain versions of MS-DOS has been known to clobber the bytes between 0x501 to 0x600, so arguably 0x501 might actually be the correct answer, although 0x600 is the de facto standard. Hpa (talk) 00:26, 18 November 2007 (UTC)

Footnotes, References or Both?

Although there's definitely a difference between these two terms, since someone else already dropped both kinds into the "References" section, for the time being I'm going to clean up the page by removing the "Footnotes" section title that has nothing under it. After reviewing other article formats, we may return it to the page. Comments? Daniel B. Sedory 12:45, 22 March 2007 (UTC)

Apparently, Wikipedia makes use of only the <ref> tag (nothing for Footnotes apart from References as discussed above), so both are now listed under "Notes and References". Daniel B. Sedory 09:47, 3 April 2007 (UTC)

Move "IBM extension" bytes in 1st Table to separate History section?

[ NOTE: This whole section has been superseded by "IBM extension bytes in EBRs (not MBR)" below. Much of this section was based on the (faulty) assumption that IBM BootManager stored data in the "Code Area" of an MBR sector. This was later proved to be incorrect.]

At the top of the page we have a table titled "Structure of a standard master boot record," yet it includes something called "IBM extensions" of 9-byte records; which I haven't been able to find a single reference to anywhere else on the Internet! Neither have I come across it in my (admittedly) small scope of experience with computers that are not IBM PC-compatibles. Anyone else encounter these? I have a feeling they are from an archaic box no longer supported by anyone, so it seems ridiculous to include this in the first table; if even under a history section. Daniel B. Sedory 10:38, 3 April 2007 (UTC)

• After examining the References which Jarsyl commented on here under "Repetitive Sentences," I noticed the phrase "IBM Boot Manager" and searched the Net for that; turns out their scheme is the same one used by ("repackaged" as many sites said) early Power Quest Boot Magic (BM) programs! I see no reason for us to keep parts of a Boot manager in our so-called Standard MBR table! It would obviously become a total mess if we included all the data from every well-known boot manager there; such as GRUB and LiLo, not to mention commercial managers, such as OSL2000. Therefore, I propose to either move such data to a separate section, or just reference it in the Notes. Daniel B. Sedory 11:08, 3 April 2007 (UTC)
  • Removing information from the encyclopaedia that you've checked and found to be verifiable does not work towards making a verifiable encyclopaedia. Indeed, it is the exact reverse of the process. I've put the information back in. Perhaps the idea that there is a standard (not something that the article used to say, and not something that is supported by the sources) is confusing you. Uncle G 13:04, 15 April 2007 (UTC)
    • Just a quick comment here to say I have noticed the recent changes (and reversions too), and wanted to thank you for splitting the "Notes and References" back into separate sections! This format is quite useful and should help with other pages as well. I'm very busy elsewhere right now, but ask that you'd consider this question: "Does this article mainly deal with the Master Boot Record sector (as its title implies) and boot loader code/data that can exist, independent of anything else once it starts executing, only within its 512 bytes, or also any other kind of program which only begins in the MBR but requires many sectors (if not separate partitions) of code and data outside it, or else it will crash?"

      Now there are obviously good reasons for mentioning some things about such boot manager programs; especially those many people may already be using. But where do we 'draw the line' between an article describing the details of any boot manager that alters the MBR, and code that can do the job of loading many different operating systems without ever altering partition data placed there by another OS? As I said above, by adding notes about data which changes the basic layout of the MBR sector, data which can only exist there WHEN the MBR and its code area have been altered by a boot manager, you have no reason to stop with only one specific program!

      PTS-DOS places some bytes where the "Optional NT disk signature" resides for its boot management functions. Shall we include that too? But neither it, nor the OS/2 boot manager can function correctly after a Windows 2000/XP install overwrites their special data areas with its MBR code! And MS-Windows, all Linux distros, BSD; all the major OS companies, do so, because vital data (pertaining to partition locations) isn't supposed to exist outside the partition table in the MBR sector. The Linux GRUB and LiLo boot managers both protect the existing 64-byte DOS/Windows partition table, and no information is lost when their code is overwritten by anything else that respects the location of that common 4-entry partition table.

      Anyway, just some things to think about; I'm not even asking for any changes right now. Would the article booting be more appropriate for discussing boot manager details? It already lists most of them. As a matter of fact, what's supposed to be the main difference between this article and that one? What separates the MBR from "booting" in general? Questions I believe any editor of this article should be considering. Daniel B. Sedory 10:11, 18 April 2007 (UTC)

      • In order: The discussion here hasn't "described the details" of IBM's/PowerQuest's boot manager. To do that would involve describing the boot manager itself, its appearance, functionality, and usage, rather than simply the MBR data structures that it employs. If we can reliably source additional MBR data structures employed by PTS-DOS, then our article is better for that content. It is untrue that what Windows 2000/XP does that causes IBM's boot manager to go wrong is related to MBRs, so an argument assuming that as its foundation is flawed. (What Windows 2000 does is scramble the Boot Manager's own partition, as this explains. It has nothing whatsoever to do with the MBR.) And the thing that separates the MBR from booting is that on several types of system it isn't involved in the system bootstrap process in any way, as this article already explains. Uncle G 23:58, 23 April 2007 (UTC)
        • Uncle_G: Very briefly, I wasn't making any reference at all to the problems Windows installs caused for OS/2 as an operating system! My point was solely that if some OS or boot software stores primary partition data outside the 64-byte table area in the MBR sector, then it's quite likely to be overwritten when Windows is installed. And that's the main diff. between All IBM/MS-DOSs, Windows, Linux (with GRUB or LILO) and any other OS that observes that table's location and those OSs or the "IBM Boot Manager" (which is included with OS/2, but does NOT have to be installed to use OS/2) which do not. Not sure why you added that last bit, obviously this article only deals with "Basic (MBR-partitioning scheme) Disks"; not GUID, etc. To put what I titled this section somewhat differently: How about splitting the data into sections? Instead of 'history' (which is what the MBR itself will be some years from now!) just add another section for those OSs and boot managers which do NOT follow the common 64-byte partition table? I'll always vote for a more logical format that actually helps the readers; even if it means dumping an idea I came up with earlier. Daniel B. Sedory 12:48, 4 May 2007 (UTC)

Copyright Issues?

I could be wrong, but isn't the binary code used by Microsoft products copyrighted? Wouldn't that include any and all code written to the Master Boot Record? I honestly don't know for sure one way or the other, but if it is, then it shouldn't be present (in hexadecimal form or otherwise) in this article.—Kbolino 02:13, 19 April 2007 (UTC)

First of all, I'm no lawyer, so if one well versed in copyright laws can add something here, great! However, I really don't see any problems. I've identified where the information has come from (everyone knows Microsoft wrote it), and it is NOT in a usable binary form, but rather text. Books on computers from many different publishers have presented the exact same format used here, for many different versions of IBM and Microsoft's MBR code. As a matter of fact, I know of some utility programs which incorporate the actual binary code in their own software, to write new MBR code just as FDISK /mbr does! I do not, however, recommend anyone do that, which is why I found a programmer to modify some GNU licensed code for Testdisk; to make every bit of it GNU GPL, instead of using the MS-DOS MBR code to restore a system's damaged MBR.

I believe the way the code is presented here: the comparison of two different MBR versions, is considered valid academic study; just as the many books written about the internal operations of Windows; and those are commercial ventures! I doubt any IT author has paid licensing royalties to Microsoft for code they showed in their books. What this article shows is only part of a disk editor view of a computer hard disk's first sector; something every PC user could do with many free tools. You can even use Microsoft's own DiskProbe or other utility programs. Daniel B. Sedory 12:54, 19 April 2007 (UTC)

I'm no lawyer either, but I find most of your arguments faulty. I will attempt to explain my reasoning:

“…it is NOT in a usable binary form, but rather text.”

The text is simply another method of representing the same data. While you are right that nothing can be done with the text as-is, it can be rather easily converted back into binary form, and it is derived directly from the original binary code.

“Books on computers from many different publishers have presented the exact same format used here, for many different versions of IBM and Microsoft's MBR code. As a matter of fact, I know of some utility programs which incorporate the actual binary code in their own software, to write new MBR code just as FDISK /mbr does!”

The presence of potentially copyrighted material in books and commercial software does not necessarily mean that those materials can be used elsewhere freely, as the publishers of those works have either a) obtained written permission from the copyright holder or b) paid royalties or licensing fees to said holder.

“I believe the way the code is presented here: the comparison of two different MBR versions, is considered valid academic study….”

As far as I am aware, this doesn't obviate the need to respect copyright holders' interests.

“I doubt any IT author has paid licensing royalties to Microsoft for code they showed in their books.”

I, on the other hand, do not doubt that. In fact, I'd be surprised if they didn't (though I speak in reference to any binary code, not just the MBR).

“What this article shows is only part of a disk editor view of a computer hard disk's first sector; something every PC user could do with many free tools. You can even use Microsoft's own DiskProbe or other utility programs.”

End users of commercial software have paid licensing fees (directly or indirectly) to, and entered into licensing agreements with, the copyright holders. They have paid for their ability to use and view the copyrighted material, which includes binary code in any form. The fact that the information is stored on their computers and readily accessible by them does not mean they own that information and can do with it as they please.

All that said, the MBR code has been around for some time, and may never have been copyrighted in the first place. In fact, it might not even belong to Microsoft. I do not know, and I think it's important to establish any ownership (or lack thereof) for this information before using it on Wikipedia. However, as I'm not really sure about any of this, I won't remove it.—Kbolino 08:33, 23 April 2007 (UTC)

I suggest you read the articles and some of their references at copyright and fair use, and then contemplate how ridiculous a state of affairs it would be if journalists, teachers, authors, encyclopedias, etc. in any media, esp. when discussing other's works (as we're doing here), would have to pay some form of royalty for ANYTHING they quoted from a copyrighted work. So no, I def. do not agree that merely quoting a portion of copyrighted materials requires either written permission or paying fees! I could tighten things up by showing even less code, and may in the future, but don't think it's necessary. You did spark an interest in me though, for more info on how to correctly display such material, so I will be writing to some well-known authors and Microsoft about this. The fair use guidelines in play here would, of course, be: "...for purposes such as... comment,... scholarship, or research, is not an infringement of copyright." Since Wikipedia is for 'nonprofit educational purposes' (right?), "the amount and substantiality of the portion used in relation to the copyrighted work as a whole" would be most important here. Daniel B. Sedory 23:14, 24 April 2007 (UTC)

Worthy of note: "the amount ... of the portion used in relation to the copyrighted work as a whole" would be all of it, assuming the "work" is copyrighted.—Kbolino 13:51, 6 May 2007 (UTC)

Note true. Does anyone think that the MBR code is a whole work that MS is selling to anyone? Of course not! It's only a tiny part (if even that; since technically an IPL is *not* an OS nor a file system) that's included within their whole operating systems. Daniel B. Sedory (talk) 07:50, 25 October 2008 (UTC)

Additional note: If you search only at microsoft.com for "33 C0 8E," you'll find at least three pages where the 2k/XP MBR code can be viewed by anyone on the Net, so no, purchasing one of their OSs isn't required to see this code! This isn't some secret encryption scheme; nor actual source code. Daniel B. Sedory 09:01, 25 April 2007 (UTC)

It would make a whole lot more sense and be a whole lot more instructive just to stick to the Linux code. From my reading of Microsoft's licence you need their express permission to put this stuff in Wikipedia.01001 06:16, 5 May 2007 (UTC)

Bash script to generate MBR code using text from article:

#!/bin/bash
mbrcode='
33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C
BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04
38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5
83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B
F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88
4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B
80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83
46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB
BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0
B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56
00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC
43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56
0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C
8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A
56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD
13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60
6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A
01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B
32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61
6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61
62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E
67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74
65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61
74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 2C 44 63'
for hex in $mbrcode ; do
  echo -ne "\x$hex"
done > mbr.code.winxp.img

--Rwcitek 13:52, 18 June 2007 (UTC)

Ah, so how's that help in deciding if there's any kind of copyright issue here or not? 67.150.171.114 08:27, 19 June 2007 (UTC)

That's a legal question and IANAL. One of the arguments above was that "... it is NOT in a usable binary form, but rather text" to which someone countered "... it can be rather easily converted back into binary form." The above script merely demonstrates just how easily one can convert from the text representation of code to binary code, in this case, fully functional and quite usable binary code. --Rwcitek 10:48, 19 June 2007 (UTC)

Could somebody please instead replace the MBR code here with something from some GPL OS? Copyright issues asside I do not think comparing two Microsoft products has much encyclopedic value.--DustWolf (talk) 13:58, 31 August 2008 (UTC)

Then look for two IPLs having similar, but different code, and compare them! There's really no point in "comparing" MBR code that was made for completely different reasons; the original comparison was to show that MBR code from two different 'eras' of the same company having different sizes will still do exactly the same thing: Boot-up/Load one OS listed in the partition table. Now someone has corrupted the whole point of what I wrote, yet still left what some above consider a copyright violation; being the latest IPL code from Microsoft! Daniel B. Sedory (talk) 07:50, 25 October 2008 (UTC)

Personally I don't see any point in having these dumps at all. They are provided without any context or indication of motivation and of questionable usefulness. Just who is going to attempt a detailed analysis of the sectors in question based of this style of presentation? It is much more likely that you'd look at a disassembly if you were that interested. Even then, a user skilled enough to gain any useful insight is more than capable of obtaining the boot sectors themselves. I think they should be removed, not on any legal grounds but simply because they add nothing to the article.

Finally, my understanding is that the very lack of any context or analysis of the sectors themselves means that it is difficult to sustain a copyright fair use argument. For our purposes, fair use applies to criticism and review of copyrighted works. Simply including a boot sector dump with no such additional commentary can't amount to fair use. CrispMuncher (talk) 17:59, 25 October 2008 (UTC)

FUD?

"Some Linux install programs will also overwrite portions of the reserved area,7 without giving you any option to protect that area! "

That sounds quite FUDish. Which programs? How? When? What the hell is this exclamation mark doing there? Hey, "Microsoft Windows will overwrite the MBR during installation without giving you any option to protect it!!!1!11ONEONEONE" —Preceding unsigned comment added by 81.168.131.12 (talk • contribs) 2007-04-22 14:52:45

• I agree that that text is cause for concern, although our concerns here at Wikipedia are non-neutrality, unsourced material, and original research, not "FUD". One concern that you haven't touched upon is where the notion that there is such a "reserved area" has come from. What source describes such a thing? Does that source pre-date the GUID Partition Table scheme (where it is explicitly defined that there are no such "reserved areas")? Uncle G 00:04, 24 April 2007 (UTC)
  • Since I'm in the process of completely rewriting that paragraph (even moving it to its own section), the "!" mark will soon disappear. Furthermore, you're definitely correct about "reserved area" (which I should never have capitalized) not having a common meaning; especially after the arrival of GUID tables! So, I've "defined" its meaning in the footnote (which I may remove if the sentence isn't retained in the text anyway). "Reserved Area" is now used by the ATA folks for something entirely different. When I can, if it's still necessary, I'll document an example(s) for my claim that some Linux installations overwrite data in this reserved area. Fact: TurboTax caused many users headaches at one time, because they did the very same thing; overwriting the Dynamic Drive Overlay code (which traditionally always resided in this area) on some user's hard disks! Remember EZDrive or Ontrack's DiskManager? Daniel B. Sedory 02:38, 25 April 2007 (UTC)

I just built a computer, and installed Debian first. It is easier to install Linux on a computer than Windows, since you can only install Windows to the HDD. You can run Debian without even having the HDD installed. Anyway I later I added a second HDD, and installed Vista. Vista will not install without insisting on writing on every mbr of every HDD in the computer and after installing Vista, you can no longer boot into Debian. This article should include an explanation of all this and further show how to recover from a Vista install.01001 05:48, 2 May 2007 (UTC)

Vista is a strictly GUID-partition OS, and having no experience with it at all, I'm not sure if Linux can co-exist with it on a dual-booting system or not. I know of ways to boot either Linux or XP from boxes that boot up either of those OSs first. I'm fairly certain that Vista has a file similar to 'boot.ini' (diff. name) that would allow you to boot up a Debian boot sector (if it had LILO or GRUB in it!) that would start your Linux OS. Win2k/xp did this for Win98/DOS with a binary file called BOOTSECT.DOS, and I can do the same thing when booting from an XP system by including a copy of the GRUB MBR sector and the appropriate line in its BOOT.INI file. IF I knew Vista could be booted from GRUB or LILO, then I'd install Vista first and Linux later, but you'd have to be sure your Linux OS install program doesn't overwrite Vista's GUID data immediately following the MBR sector! This usually means choosing to install GRUB into the Linux partition's Boot Sector (not the MBR) if you can; many install programs do not make it clear that "installing to the MBR" means they will also write a number of extra sectors immediately after the MBR sector as well. It would be nice if some distros tested for existing data before doing that, but I doubt any do. RedHat's Anaconda install program (and SuSE; as well as other newer GUI-style installers, I'd hope) give you an option to write ONLY 1 sector of code to the MBR (if you look for it). Daniel B. Sedory 12:17, 4 May 2007 (UTC)

This looks like a wipe Linux from the computer scheme to me at first glance. Is Microsoft insisting that they need all this real estate at the beginning of the hard drive to start the computer? I am still puzzled why if I installed Debian on the first HDD, Vista wouldnt allow itself to be installed on the 2nd HDD without messing with Debian.01001 01:14, 5 May 2007 (UTC)

Ah, 01001, first off, MS has *always* assumed only an MS-type OS or something similar is installed on a PC; they've never made any efforts to protect other OSs from their installs. BUT IF you read all the articles just here at Wikipedia, let alone elsewhere, you'll find that the GUID-partition is one of if not the only thing that MS actually agreed to incorporate into Vista from the much larger Extensible Firmware Interface that CPU, BIOS and various hardware manufacturers have been working on for some time! Being the type of company that MS is, though, they obviously don't want to go along with all the 'open source' proposals of the UEFI. Again, as to your specific problem, Vista is no different than Windows NT, 2000 or XP in that all of them usually require a partition with some kind of filesystem they can install files into as the first partition of the first hard disk (the 'boot disk'). So no, it's not a specific attack by MS Vista against Linux! MOST Linux users 'in the know' are, quite frankly, VERY HAPPY that MS hasn't taken a keener interest in working with Linux, because they'd probably put some system driver for accessing Linux partitions into their OSs; just imagine how 'mucked up' things would be if a Windows OSs could start writing any kind of data (or worse, erase or interact with Linux system files) on any of your Linux partitions!!! Daniel B. Sedory 06:50, 5 May 2007 (UTC)

I will concur that the referenced statement does not necessarily merit inclusion in the GPT article (and I think the article should be moved to lower p, lower t, as I don't see it as a proper noun). I would also concur that strictly in my opinion, MS generally like to dominate a system and generally make it difficult to have other systems alongside their own. Again, this is just opinion based on my knowledge and experience; there may be instances where other systems are at least on par with an MS OS.

As far as coexistence with a GPT-only OS such as Vista and beyond, this would seem to require using a GPT-aware partitioning utility such as parted and a GPT-aware bootloader. You would create a partition (assuming you can find room for it somewhere on the drive), mark its type appropriately (parted calls it a flag of "bios_grub"), and have GRUB install itself into that partition. And as far as I know, you must be using GRUB2 (GRUB 1.98) or it will not "understand" GPT. So far I have only converted a Lucid Lynx legacy partition table to a Lucid Lynx GPT, but so far it has worked out for me using GRUB as the MBR code. The Linux kernel itself seems to handle GPTs OK though. One problem may be that your Linux legacy partitions may not have been converted to GPT entries. The Lucid Lynx documentation and installer warn that GRUB2 is not yet production quality however, so you may wish to find some other Linux bootloader. The difficulty probably lies in that most software treats legacy partitions and GPT entries as mutually incompatible, so Vista is just trying to make sure Vista will be bootable. It is theoretically possible to maintain separate but congruent copies of both legacy and GPT tables, but this has the same problems as any data duplication--namely keeping the two congruent (synchronizing).

-- Joe (talk) 20:29, 20 June 2010 (UTC)

For What It's Worth... I was able to get Win7 to dual-boot with Ubuntu Linux without too much difficulty. But I gave up trying to get this to work with Vista, I finally blew away Vista and mad it a Linux Only machine... — Preceding unsigned comment added by 70.58.69.15 (talk) 05:49, 29 May 2011 (UTC)

438 vs 383 vs 446 for unix backup/restore

Why do the instructions for Unix backup/restore use 438 instead of 446? I could understand 440, since there appear to be 6 extra bytes now used (disk signature and two null bytes) at the end of the code block. I looked back in the history, and until 00:54, 26 April 2007, it was 383. I'd like to see some explanation of where these numbers come from.

151.201.109.61 18:39, 26 April 2007 (UTC)

That's what comes from having more than one operating system on my mind at the same time! Someone using *nix as their OS, certainly wouldn't be all that concerned about backing up Windows XP MBR code (though we could be speaking of a Windows OS drive's MBR being accessed under KNOPPIX or some other Linux boot CD), because a Linux user's MBR would HIGHLY likely contain either GRUB or LILO boot code; not Windows code. Therefore, I'm immediately editing the section to read '446' sectors instead. By the same logic, what used to be there made no sense either; assuming someone running the 'dd' *nix-based program, wasn't backing up an MBR with something else in it! I'll mention the 32-bit disk signature too. Daniel B. Sedory 00:56, 27 April 2007 (UTC)

IBM extension bytes in EBRs (not MBR)

Uncle G: First, I think you misunderstood my statement about what I'd found on the Internet about the IBM Boot Manager. It was only that others had said Partition Magic's "Boot Magic" software was the same as IBM's Boot Manager; and now, I'm not even sure of that (it seems that PQ had been using IBM's BM outright in version 3, but switched to their own software in version 4.something and later). I did not find anything to actually verify what has been said here of these "Four 9-byte entries" being "IBM extensions" to the "primary" partition table. I've searched many sites for anything that would corroborate this statement, and have not only come up empty (for anything about "9-bytes"), but just found someone stating the IBM Boot Manager never changed the code area in the MBR when installed; like other BMs did! (but, it's not a definitive enough source/answer).

So, can you please tell me where you got this information from? I'm asking you, because according to the 'history' here, you added this "9-byte" info on "16:24, 31 May 2006" with the comments: "(Expanded to cover MBR and GUID partitioning. Clarified introduction. Excised nonsense about "legacy MBR"s)." In the meantime, I'm still seeking more info elsewhere. Daniel B. Sedory 14:23, 10 May 2007 (UTC)

Uncle G: I believe someone misread whatever source(s) they were using. The most recent info I have on this is that the IBM Boot Manager never made changes to the MBR code area (just a new table entry for its own bootable partition), but it did store "9-byte entries" in the unused area (first 446 bytes) of extended partitions on a disk! Someone (perhaps even an author) probably mistook extended (EBR) partition table for MBR partition table? Daniel B. Sedory 09:04, 12 May 2007 (UTC)

Jan van Wijk, the author of DFSee (http://www.dfsee.com/dfsee/), has spent many years working with the internal structures of OS/2 under the IBM Boot Managers, and granted permission to quote from his reply to the following question concerning the MBR sector in an e-mail he sent on Friday, May 11, 2007. The quote begins with the question in italics:

QUESTION: I have a concern about the information someone added to the Wikipedia article on the Master Boot Record article last year for its structure under OS/2 when the IBM Boot Manager is being used.

It states that the IBM 'BM' uses something referred to as "9-byte (partition table) entries" in its own (separate) partition table in the MBR sector, and that they are located at offsets 0x018A (dec. 394) and following, through 0x01AE (dec. 430).

That is incorrect, a similar data structure DOES exist in the EBR sectors though. This same area in the MBR is occupied by boot code (as supplied by IBM).

OK, just read that part of the article (I think :-) and it seems inaccurate.

Although the info is partly correct, this data does not appear in the MBR (being the very first sector on the hard disk) but as optional data in an EBR. (being the partition-table sector for a logical partition, in the extended)

Since these structures in all the EBR sectors each describe a single logical partition, all EBR's together (the whole chain) cover the BM info for all of the logical partitions.

Since the MBR simply has no room for this info for the maximum of four partition it may describe, this info is not kept there but in the Boot manager partition itself (4th sector actually). This has an array to describe 4 primary partitions, including this same 9 byte structure.

Therefore, I am removing the incorrect comment on this from the article; though I will be adding info on this at some time in the future to the article on the EBR (completed), so the information will not be 'lost'. Daniel B. Sedory 10:21, 18 May 2007 (UTC)

Instead of removing it, how about reworking it into a "common misunderstandings" section? There seems to be a lot of faith, legend, superstition, and misinformation involved with the MBR and boot sectors. —EncMstr 15:35, 18 May 2007 (UTC)

EncMstr: Mainly because it's far from being any kind of a "common misunderstanding" IMO. But before even considering doing so, wouldn't you want to know what source that comment came from in the first place? I'm still waiting for that myself (see question to 'Uncle G' above). If it were a comment in some major Comp. Sci. textbook, journal, etc., I might agree, but there's no proof for that. I couldn't even find it on a single web site; one reason why I had to ask Jan about it, is because it's so obscure (wasn't mentioned on a single OS/2 site I visited). Only by implication, for those that *did* state 'the MBR was left unchanged when installing the IBM Boot Manager' did I first realize that was a contradiction with what had been stated here! Can you please describe a particular "common misunderstanding" that fits a lot of faith, legend, superstition, and misinformation involved with the MBR as you said? I believe the facts in the present article (though it still needs more work) already dispel any myths about it without requiring some Urban Legends of the MBR section; unless someone knows of something specific that would indeed qualify for that level of treatment. Daniel B. Sedory 02:09, 19 May 2007 (UTC)

Actually, there is one possible bit of misinformation about the MBR that could be helpful: The idea that carrying out the FDISK /MBR (under DOS) or fixmbr (under Win 2000/XP/2003 Repair Console) commands cures many different problems; which it rarely does. But shouldn't that be dealt with under fdisk or 'fixmbr'? I imagine many PC users don't know the Partition Table resides inside the MBR sector, but that's cleared up immediately in the Introduction and/or by looking at the table showing the layout of the MBR sector. Daniel B. Sedory 02:40, 19 May 2007 (UTC)

I meant the relationship of MBR to boot sector to extended partition table. People confuse those all the time. I wasn't thinking very clearly earlier, so probably missed the gist of this subtopic. —EncMstr 03:40, 19 May 2007 (UTC)

OK, yes I agree with that... which is why it's a very good thing for Wikipedia articles to include many internal links plus a "See Also" section near the bottom for pointing to all the other terms that might cause any confusion as you said, such as the EBR and others you mentioned. This intertwining of articles is one of the strong points of Wikipedia. Daniel B. Sedory 22:13, 19 May 2007 (UTC)

Uncle G, EncMstr, anyone else following my work on this topic: You may be pleased to know that I've added the information about the IBM Boot Manager to the Extended Boot Record article; including even more info than first appeared here. Note: the original comment here, about there being four partition table extensions to the Primary partition table concerns an area within the IBM Boot Manager's own bootable partition; neither the MBR nor the EBR. EBRs managed by the IBM 'BM' normally have only one 9-byte entry (1 per partition). Daniel B. Sedory 10:08, 21 May 2007 (UTC)

Run-on Sentence in Introduction implies wrong ideas

Rather than do another 'blanket edit' this time, I'll explain what I think are some misleading points and ask for others to edit or suggest corrections concerning this long sentence:

"It is sometimes used for bootstrapping operating systems, containing a machine code program; sometimes used for holding part of a disk's partition table¹; and sometimes used for uniquely identifying individual disk media, with a 32-bit data signature; although on some machines it is entirely unused."

The major problem is all the occurrences of "sometimes" which (I believe) many people will interpret as ors, rather than what is most often the case: That the MBR is used as an OS bootstrap program and has a Partition Table for determining what partition that OS is in. And when it does, it may also have a unique disk ID number. I suggest a rewrite something like this (perhaps as a separate paragraph):

This sector is often used to bootstrap operating systems by running machine code which examines its partition table¹ for a bootable (active) partition. Sometimes it contains instructions for merely jumping to code located elsewhere on the disk. It may contain a 32-bit signature for uniquely identifying individual disk media, though some operating systems never make use of it.

1) I'd write "this sector" (or 'first sector'), because writing "MBR" (Master boot record) implies something that BOOTS. But if the sector has no boot code, can it truly be called an MBR?
2) Other times (if 2nd, 3rd,... drive on a system), it can still have machine code in the sector, even though the BIOS doesn't execute it. However, an OS can still make use of any existing partition table it contains.
3) Another sentence points out that it doesn't always contain a partition table.
4) It may or may not have a 32-bit disk signature. (I understand that "machine" may be shorthand for 'Linux machine' or 'Windows machine' etc., which means the running OS, but many might think it means hardware.)

Daniel B. Sedory 10:39, 16 June 2007 (UTC)

gpart and testdisk

It would be nice to mention recovering deleted/corrupted partition tables, eg. with gpart or testdisk. — Preceding unsigned comment added by 193.59.72.35 (talk • contribs) 10:31, 21 June 2007

I second to mention "testdisk" if that is not yet the case. –89.204.153.130 (talk) 21:17, 27 June 2011 (UTC)

Requested move

Capitalization change only!
As I've already posted elsewhere, I believe this article should be listed under "Master Boot Record" (rather than "Master boot record"), since it's already redirected to from the capitalized version in internal links from various other articles, the articles for Extended Boot Record and Volume Boot Record are so capitalized, and a number of other languages use the capitalized version as well. Daniel B. Sedory 07:41, 23 July 2007 (UTC)

It isn't a proper name and shouldn't be capitalized. --Yath 04:41, 26 July 2007 (UTC)

Agreed. Instead Extended Boot Record and Volume Boot Record should be corrected. —EncMstr 06:14, 26 July 2007 (UTC)

...and have been corrected. ●DanMS • Talk 03:35, 28 July 2007 (UTC)

No you haven't! You only uncapitalized the last two words of the EBR and VBR articles! If EncMstr and SMcCandlish are correct in what they said, then you must change ALL capitalized words in the article titles; just as many dictionaries do not capitalize any words in most of their multi-word entries. (And yes, I'm aware of there being problems here in order to force the first word to appear uncapitalized; but that's true, right?)

However, the Encyclopædia Britannica (and others) consistently capitalize the first letter of all the nouns in its entries; e.g., "Irrigation and Drainage" or "Iron Mining and Processing". So, is Wikipedia really a dictionary and not an encyclopedia? The way many of its articles are titled, makes me wonder if its editors are trying to have it be both.

Anyway if you're now determined to change all such capitalized articles, you've got quite a task ahead of you. For example, GUID Partition Table. (Shouldn't that be "GUID partition table" since neither 'partition' nor 'table' are proper nouns?) And oops, right in its first paragraph there's "Master Boot Record" as a link to this article. The "See Also" sections of many computing pages here probably offer many other all capitalized words examples. Daniel B. Sedory 07:07, 30 July 2007 (UTC)

• Oppose per article naming conventions; it is not a proper name and should not be capitalized. The others should be fixed to lower case as well, with capitalized variants being redirects to the lower-case ones, and the lead fixed to not capitalize them either. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:57, 25 July 2007 (UTC)

It was requested that this article be renamed but there was no consensus for it be moved. --Stemonitis 11:08, 28 July 2007 (UTC)

I would also concur that this isn't a proper noun and therefore it does not make sense to be capitalized as if it were one, and that any references to this article should likewise have their case adjusted. I don't concur that since some other work such as Encyclopædia Britannica chooses such capitalization that WP should do it as well. I agree that cleaning up after such a move can be a monumental task, but that it should be an ideal to be sought. Perhaps this is just in my belief that it makes other Wikipedians' tasks easier when including wikilinks in their articles without resorting to [[Master Boot Record|master boot record]] syntax.

-- Joe (talk) 20:45, 20 June 2010 (UTC)

• Proper nouns are _not_ the only things which get capitalized in English. It is quite standard to capitalize the functional words in titles (of books, chapters, articles, movies, songs, etc). It can even be argued that this follows logically: the whole title of an article _is_ its name and therefore _is_ a proper noun.

118.93.19.226 (talk) 01:12, 25 July 2010 (UTC)

Proper nouns are _not_ the only things which get capitalized in English. It is quite standard to capitalize the functional words in titles (of books, chapters, articles, movies, songs, etc). It can even be argued that this follows logically: the whole title of an article _is_ its name and therefore _is_ a proper noun.

118.93.19.226 (talk) 01:11, 25 July 2010 (UTC)

I was taught that words in titles, other than prepositions and the articles 'a', 'an', and 'the', are capitalized and that the first word of the title is always capitalized; this is long-standing, traditional English writing style as found in "The Elements of Style" and "The Chicago Manual of Style." So the title of this section is properly, "Master Boot Record". However, since the master boot record is not a proper name, the words should not be capitalized when used in the text of the article except when referring to the article itself. For example: in the article, "Master Boot Record", there is a discussion of the minutiae of the bits and bytes that comprise a hard drive's master boot record. Here, the proper name of the article is correctly capitalized while the ordinary words later in the sentence are correctly lower case. The current title of the article, "Master boot record", is stylistically incorrect. Fest3er (talk) 21:31, 14 October 2010 (UTC)

Wikipedia has its own style, though it is influenced by the Chicago Manual of Style, among others. See MOS:NAME, one of our few policies (most are guidelines), for full details. —EncMstr (talk) 00:53, 15 October 2010 (UTC)

MBR Signature:

You say: MBR signature; 0xAA55

I just read mine and it actually says 55AA. —Preceding unsigned comment added by 74.134.164.46 (talk) 01:00, 7 October 2007 (UTC)

If you look at the table where we list the signature as 0xAA55, you should see that we carefully pointed out that this shows up in a disk editor as 55h in offset byte 510 and AAh in the next one (offset byte 511). For a 2-byte word on a storage medium under an Intel (PC) CPU, the byte-order must be reversed from how you would normally use it! In other words on a PC, the hex number 0xABCD will be stored in the order: CD AB. If you read the section on "MBRs and disk identity," there's mention of a "64-bit Integer, in little endian notation." Take this link if you want to read more than you'll ever want to know about this! Or, just remember that 2-, 3-, 4-, etc. byte sized words in a PC's memory or on disk are stored in reverse order, because that's how the CPU expects to find them. But when we speak or write about them as hexadecimal numbers, we use normal, human, notation; rather than the PC's "little endian" notation. Daniel B. Sedory 19:51, 7 October 2007 (UTC)

Miscellaneous Review Comment(s)

In the section "MBRs and disk identity it says "Windows NT (and later Microsoft operating systems) use the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS;" - I am guessing this should be corrected to "... as a key to an index ..." or "... in an index ..."

Jimwrightbe (talk) 19:08, 26 December 2007 (UTC)

The statement quoted seems to be confusing the physical ID of each hard disk on the system with the logical ID of each partition on the system. It also overlooks the fact that Windows 98/98SE/ME and MS-DOS also all use the signature bytes in the MBR sector as the disk's physical ID, in order to distinguish between different hard disks connected to the IDE cables. Stephen Poppitt (talk) 15:44, 1 October 2010 (UTC)

Flash drives?

The following was recently added by User:72.94.107.18 to the main text. It doesn't appear directly relevant to the article, but I decided to add it here (where I feel it should have at least been discussed first; it seems more like a discussion/questions anyway vs. article quality writing):

"* Bootable flash drives

With the increase in the number of flash drives drives in circulation, be they thumb drives or flash drives inside of USB or PCMCIA adapters, more people are wishing to boot from them, and need a sure-fire way to set them up for that purpose. Unfortunately the creation of bootable flash drives for IBM-compatible PCs is a bit of a black art and a variety of web pages exist that provide only partial answers or confused talk."

Again, I didn't write this, just moved it here from the main article. I'd like to point out, and maybe we could add something similar in the future along these lines: Not all flash drives have an MBR sector; many simply have a VBR like floppy diskettes. Anyone else care to add to this discussion? Daniel B. Sedory (talk) 01:06, 29 December 2007 (UTC)

MBR vs VBR My experience is that all the SD cards appear to come shipped with a regular MBR containing a partition table. However, if you erase that and let Windows (XP) reformat the device, it creates it using a partionless VBR. It would be good if there was a section describing how to tell the difference between the MBR and VBR? (I'm writing an embedded application and could do with that information..) 80.176.88.36 (talk) —Preceding undated comment added 11:33, 24 October 2009 (UTC).

Sector 0

It says here that the mbr is on sector 0, yet when I use int 13h, I get the mbr when I load up sector 1. Who is wrong?--DustWolf (talk) 21:47, 23 June 2008 (UTC)

Which variant of int 0x13 are you using? If it's the non-LBA, which uses cylinder-head-sector, then 1 is correct as sectors are numbered 1..n. If you use LBA, then 0 is correct. —EncMstr (talk) 22:20, 23 June 2008 (UTC)

That's true. I noted this in the article summarily.--DustWolf (talk) 19:11, 24 June 2008 (UTC)

2 TiB limit

The 4-byte LBA addresses imply a 2 TiB limit for hard drive size, assuming common 512 byte blocks. How will the MBR format be extended for larger hard drives? 1.5 TB hard drives have already been announced. Icek (talk) 20:24, 11 October 2008 (UTC)

1.5 TB disks were not only announced, but are presently in use! I've been working with one for two weeks now, and I'm sure there are a number of commercial software applications and hardware components that already need to be updated to handle this disk. Some math: Putting 0xFFFFFFFF into an MBR's partition table means it would be able to access up to 4,294,967,295 sectors. At 512 bytes each, that gives us: 2,199,023,255,040 bytes, or almost 2.2 TB; so even another 500 GB jump to 2 TB disks can still be handled by the partition table's 4-byte LBA addressing method. However, many utility programs do not presently display enough digits (or worse, have wrap-around issues). For example, if no more than a 999,999,999 sectors value could be displayed; for a size of 511,999,999,488 bytes, then a disk not much more greater than 500 GB will already cause problems for it.

The immediate answer, of course, which was already proposed years ago, is to increase the size of a "sector" to something like 1024 or even 2048 bytes, and hard disk manufacturers already have plans to do so. But, what are the implications for such a disk on our present computers? Daniel B. Sedory (talk) 06:42, 25 October 2008 (UTC)

It seems like the lower-level software needs to be changed anyway for that, so if there is no compatibility, why don't change the format (other signature) and use more than 32 bits for offset and length? And of course in a new format, the CHS addresses wouldn't be needed anymore. Icek (talk) 10:57, 27 October 2008 (UTC)

Don't forget when making any changes the IEC prefixes (like TiB) are not to be used in most articles. Fnagaton 16:05, 27 October 2008 (UTC)

MBR is dead! Long live GPT! Seriously, I do think MBR is on its last legs. GPT will be used in the future. It's already supported by the latest versions of Windows and Mac, and it's a work in progress for GRUB. However, more relevantly, I added a not about the 2 TiB limit in what I hope is an appropriate place. Superm401 - Talk 17:01, 7 December 2008 (UTC)

Edited 'Layout of one 16-byte partition record' before discussion?

I didn't realize there is a discussion page before I edited. I guess it will be taken out if it isn't appropriate.

I also see that I didn't provide any citations to the source of my information. I derived the formula by inspection through comparing the results by sfdisk and by using dd and hexdump looking at several hard drives under Linux. --Alfred1520 (talk) 04:59, 29 October 2008 (UTC)

2TiB limit, 512-byte sectors, change proposal

The hard-coded 512-byte sector in the 1st paragraph of the text I believe is wrong. elsewhere there are other places where 512 bytes are multiplied by 2³² and a place where 2TiB is mentioned as a limit without saying why (it should say that it is the limit for 512-byte sectors), and then give a table of sector sizes and upper limits.

LBA and CHS is not tied to a sector size, given what I have seen in the structures and the LBA entry in Wikipedia [1]. Microsoft has an article that warns that disk manufacturers will be coming out with large sector hard disks and that Vista will be the OS that supports it. [2]

This will probably affects mis-coded application/OS once drives beyond 2TB come out, which should be in a few months. Applications that will likely be affected should be disk management (like partitioning tools, system recovery), antivirus packages that "fix" or "defrag" the disk, and the like - anything that hard-codes a 512-byte sector.

Jmichae3 (talk) 01:05, 8 September 2009 (UTC)

Neutrality of the "sfdisk is difficult to use" statement

What's difficult for some people may not at all be difficult for others. For example, the visually impaired may be very comfortable with a text reader and the CLI whereas a GUI would be more difficult for them. Another prime example is someone logged into the machine remotely, such as via Telnet or SSH, or via iLO or a Dell DRAC. The statement seems to assume automatically that a CLI is somehow less understandable or more cryptic than other means. I personally prefer the CLI for most things, including disk partitioning. -- Joe (talk) 22:35, 20 June 2010 (UTC)

Why One Parition Editor More Suitable Than Others

I have to wonder how Ranish is more suitable to copying down partitions onto paper (or anywhere else for that matter) than other partition editors. I've used it, and have to wonder why it's mentioned in deference to say fdisk, cfdisk, parted, or any other partition editor for that matter. -- Joe (talk) 22:40, 20 June 2010 (UTC)

That whole section seems a little bit "How-To"... AnonMoos (talk) 02:39, 21 June 2010 (UTC)

References

The article mostly contains references which cite some additional information, but do not provide a source. Such use of references effectively conceals many important concepts and facts from the reader.

The information cited in such references should be reincorporated into the main article text and given proper sources where possible. --188.123.237.4 (talk) 02:57, 31 October 2010 (UTC)

Done. --Dmitry _{(talk •contibs )} 04:32, 31 October 2010 (UTC)

...a 32-bit signature for uniquely identifying individual disk media...

Uniquely? Well, maybe not.

At least, such a statement's truth likelihood is getting rather fuzzy just now.

With around 3 billion people on the planet accessing the Internet (most of them not from home, but many from their cell phones) and them having or wanting home computers but lacking home Internet connectivity, plus surplus computers dumped in low income economies where the Internet is still a rumor (rather than letting them go to waste or to component recycling), plus computers with multiple internal hard-drives or added external hard drives, or whatever, it is possible that the total number of hard disk drives in use on the planet has already surpassed or will soon surpass what 32 bits can count.

From a different vantage point, when we started (inefficiently) running out of IPV4 addresses, it should have twinged a suspicion that counts for lots of other computer oriented quantities were slouching toward their 32 bit limits,

That claim "uniquely" both needs to be taken with a grain of salt and also suggests system designers should be scampering for 64 bit media IDs becoming the norm, or even longer IDs.

I can imagine extreme case arguments, not worth sharing now, for 256 bit IDs as the norm [well okay, quantum nano-computers with cubic femtometer scale quantum hard drives hidden in the tightly wrapped string theory dimensions, and with low total particle count each, might be built with on the order of the suspected number of particles in the universe].

[Apropos of nothing at all except confessing possible personal bias on the issue, in my 288 square foot (26,75 square meter) apartment, I have at least 6 functional HDDs (3 in use) and at least one "status unknown" HDD (minus a matching CPU mounting point), within a double arm-span of me as I type this.]

I note in passing that Wikipedia could use some equivalent of a a "kvetch" status for something like the above, several tiers of importance below a "minor edit", so as neither to overemphasise to the reviewer the importance of a talk section by not checking "minor edit", nor underemphasise its unimportance by checking "minor edit".

Many of the contributions on this talk page and on thousands of other Wikipedia talk pages could benefit by having such a status available for use.

Xanthian (talk) 16:52, 11 May 2011 (UTC)

There's always been a possibility that two disks (whether hard drives or floppy diskettes) could have the same ID. However, the only practical concern this would raise is if there's any reasonable (non-miniscule) probability that two disks with the same ID would be used in the same computer (without reinstalling the operating system). You may not realize that the statistics involved are the same as those of the Birthday problem... AnonMoos (talk) 18:26, 11 May 2011 (UTC)

P.S. GUID Partition Table goes with 16-byte ID's (see stats at UUID#Random_UUID_probability_of_duplicates). AnonMoos (talk) 18:37, 11 May 2011 (UTC)