Talk:Boot sector

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 

2006[edit]

This should be merged with Master boot record. 71.250.15.252 23:53, 14 April 2006 (UTC)

I agree to some extent. The MBR has a completely different format than a boot sector. It is important, when programming an OS, to realize that the very first hard disk sector (the Master Boot Record) contains the partition information and also contains the initial boot program (the Master Boot program) -- which then (typically) loads and runs another completely separate program (the code in the boot sector) -- which then typically runs another completely separate program (the OS-specific bootloader), which then actually loads and runs the operating system.

To explain this in the MBR article would make that article a little more complex, but more useful. BruceEwing 22:38, 9 May 2006 (UTC)

The last paragraph explaining the vulnerability to boot sector viruses is unclear -- can someone clarify? 4.18.224.163 23:02, 30 September 2006 (UTC)

stub[edit]

unsure of wether this article is a stub

removed sentence[edit]

I removed this sentence:

Because of this vulnerability, computer security experts tend to recommend that booting from devices other than the one containing the installed operating system, such as removable media devices (e.g. floppy disk devices, CD-ROMs, and USB flash drives), be disabled in normal operation via the BIOS setup utility, and only re-enabled on those specific occasions when booting from such devices is actually required.

This fails WP:WEASEL, as it invokes a "voice of authority" that isn't attributable to a reliable source. If someone wants to reinsert this with a sourcable attribution, go for it... -/- Warren 09:22, 19 December 2006 (UTC)

I find it is a shame that concern for policies disable the most important piece of information in this article. As long as real life, good knowledge has to make way for some guru signature, we got the wrong set of priorities in WP. yamaplos 19:07, 23 March 2010 (UTC) —Preceding unsigned comment added by Yamaplos (talkcontribs)

Proposed merge[edit]

I've proposed merging bootblock into this article, because I think they're two names for the same thing - boot sector seems to be a PC-centric term, whereas bootblock is used on other systems (VMS, Amiga, etc.).—greenrd 01:22, 15 April 2007 (UTC)

greenrd, I agree! I believe any internal links to bootblock should be redirected to this page, and the article expanded. This name confusion happens to have been on my mind a lot lately, as a matter of fact, I'm trying to find out WHEN the term sector took over for what many had used the term block for in computing fields! (BTW, I noticed your minor edit to a page I've spent a great deal of time on recently, Master_boot_record, so that's why I came here.) See my recent edits to Disk_sector for example, on this idea. Daniel B. Sedory 09:16, 15 April 2007 (UTC)


GRUB as an MBR or VBR vs ordinary Volume Boot Records[edit]

[Note: I mistakenly placed this section here instead of at Talk:Volume boot record, but I'll leave it here, since it might be helpful to those interested in GRUB and VBRs.]

I just finished 'undoing' an addition by User:Smwikicn2007 [at Volume boot record] in which he called the VBR a virtual MBR on non-partitioned devices. Later, this made me wonder what might have led him to make such a statement. Could it be the fact that GRUB (often found on computers running Linux) can actually be set up to act as either a Volume boot record or a partitioned device's Master boot record? If so, this may have led him to believe that any VBR code could also be thought of as an MBR on bootable devices that do not have a partition, such as floppy diskettes.

GRUB's 512-byte stage1 contents can perform either function, because it was not only created with executable code meant to run correctly after being loaded into memory at 0x7C00 by a master boot record, but also contains the usual 64-byte partition table that many utility programs expect to see in an MBR; especially those on hard disks with a bootable Microsoft operating system. Daniel B. Sedory 07:23, 22 September 2007 (UTC)

Dubious[edit]

I have added a dubious tag to the sentence attempting to differentiate between boot sectors and boot blocks. I have seen both terms used for both platforms cited and it appears to me that this is a distinction that doesn't really exist. CrispMuncher (talk) 21:57, 9 July 2008 (UTC)

Well, no one came up with any references so I've gone ahead and deleted it. CrispMuncher (talk) 16:38, 20 August 2008 (UTC)

"boot block"[edit]

The only sources I could find, that are even halfway reliable, discuss "boot blocks" in the context of a BIOS, namely it is an immutable ROM that allows the BIOS to be re-flashed in the event of flash corruption. Judging from these sources, the term is not related to mass storage devices, and hence is off-topic when discussing boot sectors in this context. I have basically reversed the merge that was conducted in 2007 (as discussed above). Ham Pastrami (talk) 08:18, 1 April 2009 (UTC)

Sorry, I didn't notice this until now when I cam looking for something else. I'm now aware of any such distinction and if there is one it is purely PC specific. The very first place I looked found a reference for boot block referring to a disk sector [1]. I notice that boot block is currently redirecting to BIOS which seems highly dubious to me. CrispMuncher (talk) 20:35, 15 November 2009 (UTC)

Boot signature[edit]

Relying on an unstated endianness for the AA55 signature isn't very clear. Something like "the two-byte sequence 0x55, 0xAA" would be unambiguous.Ewx (talk) 08:56, 18 January 2010 (UTC)

I don't have a problem with that. The problem with the recent edit was that word has a clearly defined meaning and since that treatment is restricted to PCs a PC's byte order is implied.
Also I've just noted that the rest of the first paragraph dealign with the issue is misleading. Most machines will not report an error at all. Instead they will simply regard that medium as non-bootable and proceed to the next drive in the boot order. Remember that the non system disk error you get from a DOS formatted floppy is the result of a valid boot sector being executed and halting the process. CrispMuncher (talk) 16:14, 18 January 2010 (UTC)

The magic number 0x55 0xAA at the end of the sector is NOT important for BIOS, may be for DOS (and later Microsoft OS). I can proof it: CP/M-86 does NOT have such magic numbers in the boot sector but can be booted (even on a modern machine, see http://www.z80.eu/blog/ !). Code will be loaded at 0000:7C00 and BIOS will jump to the first byte after loading the sector, regardless what code is "hidden" in that sector. — Preceding unsigned comment added by 95.89.156.66 (talk) 19:23, 17 August 2012 (UTC)

At least the BIOS of the original IBM PC does not test on this signature before passing execution to the boot sector, however, it only supported floppy drives, no hard disks. Most BIOSes today should check the signature at least when booting from hard disk (details need to be sorted out).
Any standard MBR code will check the signature before passing control to a boot sector, and most multi-boot loaders will do it as well. So, you might have luck booting from floppies, but not from harddisk.
Regarding DOS, old versions of DOS actually checked for this signature to be present before accepting a volume, however, there are FAT formatted floppies without this signature in the wild, so this was removed and replaced by a more sophisticated check utilizing the jump opcodes at the start of any DOS 2.0+ FAT formatted floppies as an indicator of the presence of a BPB. If not (as on DOS 1 floppies), these DOS versions use the FAT ID byte at the start of the FAT to detect the proper FAT format. More information in the FAT article. --Matthiaspaul (talk) 20:47, 17 August 2012 (UTC)

I can even boot CP/M-86 from harddisk. And no, it was not "at least" an original IBM PC, it was the Phoenix BIOS implemented in VMWare Player 4. I already pointed to that blog (see above), you can look at these screenshots. MBR code is OS related, at least code fragments which are loaded by the BIOS. But I can confirm that this CP/M-86 MBR has two "magic bytes" at the end of the MBR at least. Not sure how to display the boot sector of the (virtual) harddisk, maybe by using a DOS disk editor. — Preceding unsigned comment added by 95.89.156.66 (talk) 21:52, 17 August 2012 (UTC)

I suggest trying it on real hardware as opposed to a virtualised emulation of that hardware and citing it's behaviour as definitive. It's certainly true that not all PCs pay attention to the signature, and it may well not be valid on the oldest PCs (although I can't see it having come in later than the AT), but it is equally true that many or possibly even most do. All Award BIOS systems I've ever tried pay attention to it, as do true IBM BIOSes on some older ThinkPads I have here. The only AMI BIOS system with a floppy here is a server I'd rather not take down right now to test. Even if the systems performing the check were in the minority (which they do not appear to be) the net effect would be moot - no-one releasing any software could afford to say "We don't support those 25% of machines out there for the sake of two bytes at the end of one disk sector."
In any case, there is still no source provided that a) shows this on hardware and b) does not rely on inappropriate amounts of inference. Where is the source that directly makes the point that contradicts every specific description of the PC's boot sector layout? Consider for example this Microsft source [2] which makes clear that it is the BIOS that first checks for the signature. Crispmuncher (talk) 02:48, 18 August 2012 (UTC).
There is BIOS source code online e.g. at http://www.intel-assembler.it/portale/5/ibm-at-286-souce-code/ibm-at-286-souce-code.asp which enforces these rules: for a hard disk the 0xAA55 signature check is made, while for a floppy disk the rule is that the first byte of the boot sector must be less than 0x06 and the first 9 words must not all be identical. While that doesn't reveal the distribution of signature checks in modern BIOSes, it does provide a latest date for their introduction. Ewx (talk) 08:16, 18 August 2012 (UTC)
Nice find, thanks. Small correction: On floppies, the first condition is that the first byte must be greater or equal to 06h (not smaller). Quite interesting, the source code comment suggests, that the code checks that the byte is not 00h, whereas it actually checks that it is not smaller than 06h. Similarly strange, the second condition is described as checking for the first 8 16-bit words not to be all equal, but the code actually compares the first 9 words (as you wrote correctly). --Matthiaspaul (talk) 13:13, 18 August 2012 (UTC)
First byte: sorry, yes, somehow the sense got reversed between brain and fingers l-) The error in the first comment is especially hard to explain, isn’t it? Ewx (talk) 07:43, 20 August 2012 (UTC)
Just a few more notes:
a) The MBR code is meant to be OS-independent and there's a quite well-defined (although badly publically documented) list of tasks to carry out by that code (I know that not all 3rd-party MBR code today adheres to these rules). Of course, the code can have extensions, for as long as it also performs the basic tasks. Anyone is free to write his own MBR, but not sticking to the rules he will give up compatibility with the rest of the world.
b) CP/M-86 does not need a special MBR code to boot, a standard MBR should be okay as well.
c) The ROM-BIOS of the original IBM PC really does not check the signature (I have checked it in the source code), but I fully agree with Crispmuncher, many if not most BIOSes today (and for a long time) have checks in place.
d) The presence of the 55h AAh signature must be interpreted as "this volume is bootable on IBM PC compatible x86 machines". It does not indicate any particular file system or operating system. It does not indicate that the volume is actually bootable, but at least a dummy bootstrap loader must be present in order to "catch" the x86 CPU in a tight loop or such instead of crashing (crashing is dangerous - I have even seen crashing boot loaders accidently destroy the contents of the flash so that the machines became non-functional until the BIOS chips were reflashed externally). Volumes, which are structure-wise compatible with those used in the PC world, but which contain boot code for other platforms (for example FAT volumes on Atari ST (68000) or MSX-DOS (Z80) must not contain this signature (unless they contain dummy x86 loaders), so that the (modern) PC BIOS or MBR will not attempt to pass execution to it. As I wrote, modern versions of DOS (once booted) have no problems to mount FAT volumes even if the signature is not present (this should also hold true for other operating systems or they should be fixed accordingly), but the signature must be present to boot. Since DOS always writes at least a dummy x86 boot loader when formatting a volume, it also writes the signature. Unfortunately, there's too much bad documentation and code in the wild to make this a 100% reliable scheme. Some non-x86 bootable disks have the signature, although they should not (because people didn't knew what it stood for exactly), and some very early x86-bootable disks don't have the signature although they are bootable on PCs. --Matthiaspaul (talk) 10:21, 18 August 2012 (UTC)

Again many wrong assumptions, at least what you're talking about compatibility. I booted CP/M-86 with a Thinkpad T23, see at the above mentioned blog ( http://www.z80.eu/blog/ ). A Thinkpad T23 is not "the oldest" one, and I've managed it to boot CP/M-86 also with my Compaq Portable II. Why do you still claim here "if not most BIOSses .... have checks in place" ? Test it - try yourself booting CP/M-86 with a real existing PC. Don't make just theoretical assumptions only. — Preceding unsigned comment added by 95.89.156.66 (talk) 18:17, 18 August 2012 (UTC)

Try reading the above comments, not ignoring them and basing your position on your own assumptions. This has been tested, and there are plenty of sources that back this point up as noted above. Al we all making this stuff up? Where is your source that states explicitly and definitely this is all wrong? Until that point all we have is one man's original research. Crispmuncher (talk) 19:22, 18 August 2012 (UTC).

I just verify what was stated. Directly, in real life. I do not dispute that other sources/articles telling a different story. Many times somebody/a company wrote something, and others copied that in their own contributions then. How many real PCs have I to show until you believe that booting such a floppy disk is not a singular occurence ?? I guess it doesn't matter, you will still write something copied from your own sources and say, "it's one man's original research", it's not enough. Be brave, just try to boot CP/M-86 on a modern PC of your own choice in reality (but not with an USB floppy). — Preceding unsigned comment added by 95.89.156.66 (talk) 19:32, 18 August 2012 (UTC)

Again, read what I wrote. I've verified this myself:
  • Three Award BIOS machines.
  • A ThinkPad 560
  • A ThinkPad 600
None of these work. As noted above no-one disputes that there are machines that skip the test, but equally unless it works everywhere (or close enough to everywhere that it makes no difference) it is essentially a moot point. Crispmuncher (talk) 19:40, 18 August 2012 (UTC)

Ok, so just reflect this in the wikipedia article and state there, it is checked by some machines, not by all. Also, check made for harddisk was not contested by myself. Just for *FLOPPY DISK*. Read my statements also a bit more precise, thanks. AND BTW. - even that microsoft KB article states only that an MBR (NOT A FLOPPY DISK BOOT SECTOR) must have 55 AA at the end. Give me a more precise reference, thanks in advance. Also, I showed a photo as a proof, and I can describe how I tested and how I transferred the floppy disk content. E.G. if you are using QEMU for testing, floppy check can be switched off with a specific option. You just wrote "I've verified this myself", but you didn't explain how.— Preceding unsigned comment added by 95.89.156.66 (talk) 19:48, 18 August 2012 (UTC)

Hmm, I've verified that the 0AA55h signature is not required for a floppy bootsector on Dell Latitude CP (pentium), Dell Dimension 8400 pentium4, 8250 pentium4, XPS T850r, Sony VAIO pentium4. Rather than quibble, test:

;;-----------------------------------------------------------------------75
;; File: boot0.nsm  By: s_dubrovich at yah**  .com
;; ?(c): COPYLEFT
;; Last: Mon 27 Aug 2012 09:58:00 AM CDT 
;; Prev: Sun 26 Aug 2012 10:51:43 PM CDT
;; Init: Sun 26 Aug 2012 10:51:43 PM CDT
;; Vers: 0r0
;; Goal: floppy boot sector without 0AA55h signature.
;; Desc: floppy boot sector without 0AA55h signature.
;; Cmmt:
;;  Demonstrate that a floppy boot sector loads without AA55h signature.
;; EndCmmt:
;;-----------------------------------------------------------------------75
;; nasm -@boot0.mak
;;
;; boot0.mak contents:
;; -f bin
;; -l boot0.lst
;; -o boot0.bin
;; -Z boot0.err
;; boot0.nsm
;;-----------------------------------------------------------------------75
;; To Test under Linux (debian):
;; 1. format a 1.44mb diskette as for pcdos.
;; 2. In Linux, in current working directory, to write boot0.bin to the
;;      diskette bootsector, do:
;; 3. $ disk=/dev/fd0
;;    $ dd bs=512 <boot0.bin >$disk
;;      1+0 records in
;;      1+0 records out
;;      512 bytes (512 B) copied, 0.265273 s, 1.9 kB/s
;; 4. shut down linux
;; 5. power-on reboot with the floppy already in the drive.  If 0AA55h
;;      is not required, a message is printed:
;;      "Loaded Boot Sector without AA55h Signature. "
;; 6. remove the floppy from the drive, and press any key to reboot as
;;      normal.
;;-----------------------------------------------------------------------75
;; Sun 26 Aug 2012 10:51:43 PM CDT - v.0r0, initial.
;; Mon 27 Aug 2012 09:58:00 AM CDT - descriptive edits.
;;-----------------------------------------------------------------------75

number_tracks   EQU 80  ;; 3 1/2 1.44 mb
number_sectors  EQU 18  ;; 18spt

LF      EQU  0Ah                        ;; ASCII LINE FEED
CR      EQU  0Dh                        ;; ASCII CARRIAGE RETURN

     [BITS 16]

;; Rombios loads this to 0000:7C00h, DL==boot drv.
;; Compaq Rombios loads to 07C0:0000h

[SECTION .text vstart=0] 
 
BS_jmpBoot:
        jmp     START

;;-----------------------------------------------------------------------75
;; win95 overwrites BS_OEMName, don't depend on it.

  BS_OEMName            db "BOOTSECT" ;; OEM_ID
  BPB_BytesPerSec       dw 0200h
  BPB_SecPerClus        db 01h 
  BPB_RsvdSecCnt        dw 0001h
  BPB_NumFATs           db 02h
  BPB_RootEntCnt        dw 00E0h
  BPB_TotSec16          dw 0B40h ;;720k=05A0h
  BPB_Media             db 0F0h
  BPB_FatSz16           dw 0009h
  BPB_SecPerTrk         dw 0012h
  BPB_NumHeads          dw 0002h
  BPB_HiddSec           dd 00000000h ;preceding vol
  BPB_TotSec32          dd 00000000h ;small vol
  BS_DrvNum             db 00h
  BS_Reserved1          db 00h
  BS_BootSig            db 29h ;;indicates the next
;; three fields are valid, newer fat spec
  BS_VolID              dd 0FFFFFFFFh
  BS_VolLab             db "SOME_VOLUME"
  BS_FilSysType         db "FAT12   "

;; added local string, not a part of the specification.
  BS_Img_Vers           db "No sig vers. 0r0"

;;-----------------------------------------------------------------------75
;; code located at 0000:7C00.

START:  ;; adjust segment registers

        cli
        mov     ax, 07C0h
        mov     DS, ax
        mov     ES, ax

;; create stack

        mov     ax, 0000h
        mov     SS, ax
        mov     sp, 7C00h
        sti

;; put message to console

        mov     si, msgSig
        call    DisplayMessage

;;-----------------------------------------------------------------------75

AllDone:
        mov     si, msgReboot
        call    DisplayMessage
        mov     ah, 00h
        int     16h             ;; await keypress
        int     19h             ;; warm boot computer

;;-----------------------------------------------------------------------75
;; PROCEDURE DisplayMessage - display ASCIIZ string at ds:si via BIOS
;;-----------------------------------------------------------------------75

DisplayMessage:
        lodsb                   ;; load next character
        or      al, al          ;; test for NUL character
        jz      .DONE
        mov     ah, 0Eh         ;; BIOS teletype
        mov     bh, 00h         ;; display page 0
        mov     bl, 07h         ;; text attribute
        int     10h             ;; invoke BIOS
        jmp     DisplayMessage
.DONE:
        RET

;;-----------------------------------------------------------------------75
;; D A T A
;;-----------------------------------------------------------------------75

msgSig: db 0Dh, 0Ah, "Loaded Boot Sector without AA55h Signature. "
        db 0Dh, 0Ah, 00h

msgReboot: db 0Dh, 0Ah, "Remove diskette, Press Any Key to Reboot", 00h

        TIMES 510-($-$$) db 0
;-;     dw 0AA55h
        dw 0000h

;;-----------------------------------------------------------------------75
;; - E O F -
;;-----------------------------------------------------------------------75

The one system configuration I do have that requires the sig is an old xt clone, but only if the scsi hd controller, a seagate ST-01, is installed. This is because the ST-01 option rom revectors int 13h to its own int 40h, and it is that controller's firmware which checks for the sig. Replacing the controller with a Future Domain scsi controller, cures that 'feature'. --2012-08-27T20:22:23‎ User:Zekeseeker

Thanks for the follow up. Some quick comments:
  • There's a CLD missing in the code.(--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- Noted, although CLD is the default state at the end of the POST, going into the bootstrap, it is better to be explicit.(--Zekeseeker (talk) 15:48, 28 August 2012 (UTC))
  • Do you known which Compaq ROM BIOS loads at 07C0h:0000h instead of 0000h:7C00h? While this works most of the time, it is against the spec and will definitely not work with all code in the wild.(--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- Circa Compaq Presario 4770, Pentium MMX. Granted pretty old. It's not cabled up, otherwise I'd check what bios it uses.— Preceding unsigned comment added by Zekeseeker (talkcontribs) 15:48, 28 August 2012 (UTC)
I've seen both options used in different sources but it doesn't make any difference in reality. Ultimately 07CO:0000 and 0000:7C00 are the same address. Crispmuncher (talk) 14:30, 29 August 2012 (UTC).
  • I don't think it will, but by providing an EBPB you risk that a BIOS will perform more elaborate tests by relying on the BPB rather than the signature. Not necessarily a problem, but please note that the chosen OEM label and serial number would cause hickups with various operating systems, and the media ID would not be okay for 720 KB either. It is important to ensure that the first jump is a NEAR jump, because otherwise the BPB would be misaligned (many assemblers would optimize this into a SHORT jump without explicite labeling). I would have filled the sector with F6h, or if you want to be nasty: 01h 01h 01h 01h 01h 01h ... (--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- If one were to post-process this floppy under various OS's then that is of concern. I know XP does extra checks, so it won't accept bootsectors too far from its 'normal'. If you were working on a diagnostic floppy bootstrap that didn't have a BPB, under XP you would have to reformat it before writing a new version to it (been there).
- To be clear, you can have a SHORT jmp followed by a NOP as the first jump, I've seen both used. (I use, and promote, nasm, so I know what it will do in this case as far as (not) optimizing the jmp. There is the .lst listing file to consult if in doubt - such as to make sure the TIMES padding is correct.) (nasm uses a default filler byte of 90h, NOP, for code sections if not told to use something else, and 00h, NULL for data sections. I would not use F6h myself, as this is default filler byte of the format operation, I'd be concerned it might cause confusion for some utility or perhaps bios code, same for using E5h, the prior-art format filler byte.(--Zekeseeker (talk) 15:48, 28 August 2012 (UTC))
  • Anyway, why don't you just use a DOS floppy boot image and patch the signature in a disk editor or with DEBUG etc.? Much less work...(--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- You could, probably much less work for you. But I have this linux box, and nasm, at hand at the moment.(--Zekeseeker (talk) 15:48, 28 August 2012 (UTC))
  • How do you perform the test on hard disks?(--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- You don't!! The boot sector on the hard disk _is_ the MBR, messing with that will give you grief. (I'm not sure that everyone has the same definition of what a boot sector is: it is the first sector loaded by the rombios from the bootable device. Period. (I'm saying this for the benefit of the wider audience))
  • General question: Will these BIOSes perform other sanity checks or will they just crash the system when inserting a floppy containing garbage?(--Matthiaspaul (talk) 19:39, 27 August 2012 (UTC))
- Other sanity checks are performed. For example, defining garbage as:
[SECTION .text vstart=0] 
 
        TIMES 506 db 90h

        int     16h             ;; await keypress
        int     19h             ;; warm boot computer

        TIMES 510-($-$$) db 90h

        dw 0000h
- ..then this seen as non-bootable and then skipped for the next bootable device, or a some message is printed (Strike F1 to retry boot, F2 for Setup Utility), on my systems that I've tried. I'm not sure of what the rombios is checking --
- The scope of the discussion is regarding the floppy boot sector signature.
- --Zekeseeker (talk) 15:48, 28 August 2012 (UTC)

Btw. Matthiaspaul has just no idea what he does and talk about. He told me a few days ago (here), he "tested" also a Thinkpad 600E and he wasn't able to boot CP/M-86. Meanwhile I had access to such a Thinkpad and voila, of course I was able to boot CP/M-86 also on that "tested" notebook. For a photo, visit my blog (see above for an URL). — Preceding unsigned comment added by 84.163.72.123 (talk) 18:57, 30 August 2012 (UTC)

Huh? Please be very careful before making personal attacks. We don't tolerate them here at Wikipedia. Just for the records: I never even remotely stated anything as such.
Since you write as an IP and mention "your blog", the only blog mentioned in this thread was http://www.z80.eu/blog/. I had a look when it was first mentioned, but since it was full of factually wrong statements and bad language, I did not consider discussing it. If this is your blog and you are the same user as User:Zekeseeker, then please log in, if you are interested in a serious facts-based discussion. And I seriously advice you to get your facts straightened out before you make accusations. --Matthiaspaul (talk) 19:31, 30 August 2012 (UTC)

Excuse me for this, it was "Crispmuncher", *not* you. Despite of this, there are no factual wrong statements and bad language, except that I've cited the wrong name (changed this in my blog). You still insist in *your* wrong assumptions and you even can't give me a reliable source for citation of the need of a 0x55 0xAA pattern in a *floppy* boot sector (and you can't proof it by yourself, I can...). And no, I am not Zekeseeker. — Preceding unsigned comment added by 84.163.72.123 (talk) 20:26, 30 August 2012 (UTC)

Where did he refer to a 600E? Or booting CP/M? He didn't do either so your complaint amounts to "I didn't read what he had to say, made something up in its place, and the stuff I made up is wrong." Do you wish to withdraw those comments which DO amount to a personal attack? Justin Urquhart Stewart (talk) 03:55, 12 August 2013 (UTC)

How current?[edit]

How prevalent is boot sector infection in March, 2010? I remember it used to be a biggie in the days we booted from floppies, but nowadays participating in a massive USB-Flash-based educational project, Sugar-on-a-stick, I am concerned we are putting our users at risk if their sticks get infected and then infect computers wholesale, but I cannot find reliable information either way. Thanks if someone can update the article to show current risks, if any. yamaplos 19:10, 23 March 2010 (UTC) —Preceding unsigned comment added by Yamaplos (talkcontribs)

Well, its still there, albeit it may not be quite as visible as it once was. Boot sector viruses became less of an issue post Windows 95 so perhaps boot sectors have dropped off the radar as far as the average user is concerned but they are still of vital importance. Most of it hasn't even altered that much - it needs to remain the same for the sake of IBM compatibility. The only real change has been evolution in supported boot media - first CD-ROMs and now USB drives, although those are more BIOS changes that changes to the actual boot sectors themselves. CrispMuncher (talk) 21:47, 23 March 2010 (UTC)

possibly incorrect information[edit]

"On IBM PC compatible machines, the BIOS is ignorant of the distinction between VBRs and MBRs, and of partitioning". This doesn't seem to be entirely true. If you place an MBR on a USB key, and boot it as your primary device, the BIOS assigns a number of 0x80 (first hard drive) to it, as seen by the contents of the DL register. If it has a VBR, the BIOS assigns number 0x00 (first floppy drive) to it. At least that's the case with my laptop (emachines E625) John Comeau (talk) 15:04, 13 June 2010 (UTC)

That's just the content of the DL register for INT 13 (00 ending in the floppy code, 80 ending in the hard disk code). Unpartitioned => no MBR => (super)floppy => 00. Partitioned => MBR => hard disk => 80. What you see is as it should be. The article claims that USB-sticks are always a superfloppy, that's wrong. I have a 32 MB USB-Stick (it was a gift ten years ago) with a partition, works as expected - well, I don't use it as a boot device. Formatted as a superfloppy it also works as expected. This article here is IMO pointless. Anything about an MBR can go into Master Boot Record with a subsection for the "EBR" (extended partition "MBR") business. Anything else can go into the "VBR" article, and explain ordinary boot records (depending on file and operating system, they typically have to look for a specific file with more code in their partition or superfloppy). –89.204.153.227 (talk) 10:21, 18 July 2011 (UTC)
2nd attempt, what I've written didn't answer your question. Without ever testing it I'd guess that El-Torito is a CD-ROM handled as floppy, not as a hard disk. If that is correct it would be always 00 like a real floppy — any general boot code using BIOS INT 13 needs to know what it has to put in DL, 00 or 80. The BIOS knows that it's talking with a CD, but the boot code on the CD expects to be a floppy. For an USB-stick it can be both, an unpartitioned superfloppy would use 00 because the BIOS again tries to emulate a floppy. A partitioned USB-stick begins with its MBR code, this MBR code would assume that it is a hard disk, and use 80 when it transfers control to the one and only active partition (if there is an active = bootable partition). IOW, it would be this MBR that uses 80, not the BIOS. The BIOS only executes the first sector of the first found boot device, and after that it has to accept 00 or 80 for USB-sticks. I hope this is clearer, and ideally correct, but you asked one year ago, please wait for a second opinion ;-) –89.204.153.227 (talk) 11:07, 18 July 2011 (UTC)
Actually, the stick is internally configured (in the controller) to be either a removable drive or a superfloppy. The BIOS asks the USB stick (or other disk-like device) what type of medium it is, and if it is a removable drive / harddrive it assigns drive unit 80h, otherwise drive unit 00h to it. If there are more disk devices, they will be assigned units 81h, 82h, etc. or 01h, 02h, respectively, all the way up to FEh and 7Eh. (Values FFh and 7Fh are reserved for internal purposes.) So, in theory there could be up to 127 removable drives and 127 superfloppies in a system.
You are right that most MBR code just assumes to be drive unit 80h, but modern BIOSes pass the drive unit to the boot sector / MBR as part of the register interface (DL = drive unit) and modern MBR code and boot sector code will actually use this instead of the fixed 80h / 00h values (sometimes after some sanity checks, since some very old BIOSes do not support the DL parameter). --Matthiaspaul (talk) 21:03, 17 August 2012 (UTC)

Too PC-centric[edit]

This article is PC-compatible specific and implies that all computers behave the same way and run some form of a Microsoft operating system.  Most non-PC systems handle boot from disk very differently than a typical PC.  Can we make this sort of information clear to the reader as well?

Bigdumbdinosaur (talk) 02:38, 29 November 2010 (UTC)

Apparently Booting does what you wish, there are too many articles for this fascinating topic. –89.204.153.227 (talk) 12:21, 18 July 2011 (UTC)