[jaclaz]

The MBR is NOT the bootsector.

This is where you probably are confusing matters.

Normally the bootsector of first partition is at sector 63 (CHS 0/1/1) on "legacy" systems (up to XP/2003) and on sector 2048 (CHS 0/32/33) on Vista /2008/7 (if not patched to follow "legacy" Rules)

The MBR is NOT part of the volume, it is part of the disk.

Review this:
http://mirror.href.c...r/DiskTerms.htm
http://mirror.href.c...skTerms.htm#LOC
and take some time on the Starman's pages to understand the structure of disks and partitions and volumes and filesystems.

First sector of a hard disk (sector LBA0) is the MBR or Master boot record.
The bootsector of a partition starts at first sector of the partition or volume, as said for first partition it is normally LBA 63 or 2048 depending on the OS that partitioned the volume.
More generally you read the partition table in the MBR (and for extended partitions in the EPBR chain) to know where the bootsector of a given partition starts.
FAT 12/16 the bootsector is 1 sector long
FAT32 the bootsector is actually 3 sectors long, first, second and third if formatted under DOS/Win9x/Me:
http://mirror.href.c...mbr/MSWIN41.htm
first, second, third and thirteenth:
http://mirror.href.c...FAT32brcomp.htm
if formatted under 2K/XP and later
(for the record, for unknown reasons the FAT32 of ReactOS uses 15th sector innstead of 13th)

jaclaz

[submix8c]

After looking at your ZIP attachments, a further clarification (re - jaclaz) is in order.

Sectors are (generally) 512-bytes long. The MBR is one sector (always 1st sector). Each PBR is as-stated above and is JUST the 1st three sectors of the beginning of any given partition (Volume, if you will). Each Partition is "pointed to" by the MBR Partition Table. Each Partition has a Reserved Area for the Root Directory. All Files and further Directory/File chains lead off of the Root.

There are rules that must be followed for 16-bit/32-bit/(other, e.g. 48-bit) operations and the info is usually stored in the associated places in the HDD according to the formatter being used. It's the code/stored-info combo that's maybe confusing you. ("why this does this and that does that?"). It's the point that's been made already (albeit vaguely).

Go get a Trial version of Hex Workshop - it allows to read each singe Physical Drive and each Logical Partition. Just for fun, then you may understand... (along with StarMan's great information).

This post has been edited by submix8c: 07 March 2011 - 06:54 PM

[dencorso]

wsxedcrfv, on 07 March 2011 - 09:24 PM, said:

PS: If there is a third boot sector as part of the Boot Record, is there any similar pointer to it's location? And a description of it's contents?

It's complicated... FAT-32 always uses 3 sectors for the boot structure, however:

1) If the OS is MS-DOS,
LBA0 is the boot sector that loads IO.SYS and LBA6 is its backup;
LBA1 is the FSInfo sector and LBA7 is its backup;
LBA2 has the second part of the boot code (and is pointed to from within the code in LBA0) and LBA8 is its backup.

2) If the OS is Win 2k/XP/2k3,
LBA0 is the boot sector that loads NTLDR and LBA6 is its backup;
LBA1 is the FSInfo sector and LBA7 is its backup;
LBA2 is blank (or has whatever contents it had before), and so is LBA8!
LBA12 has the second part of the boot code (and is pointed to from within the code in LBA0), and has *NO* backup!

3) If the OS is ReactOS,
LBA0 is the boot sector that loads FreeLoader and LBA6 is its backup;
LBA1 is the FSInfo sector and LBA7 is its backup;
LBA2 is blank (or has whatever contents it had before), and so is LBA8!
LBA14 has the second part of the boot code (and is pointed to from within the code in LBA0), and has *NO* backup!

See:

jaclaz, on 23 September 2010 - 03:04 AM, said:

http://www.boot-land...opic=7739&st=92
http://www.boot-land...opic=7739&st=99
http://mirror.href.c...ex.html#ntfat32
http://mirror.href.c...ex.html#mswin41

http://mirror.href.c...r/ntFAT32BR.htm
http://mirror.href.c...FAT32brcomp.htm

And this Tutorial about ReactOS

[rloew]

wsxedcrfv, on 07 March 2011 - 06:40 AM, said:

rloew, on 06 March 2011 - 11:53 PM, said:

I'm not sure how far FORMAT.COM can go, but VFAT.VXD has a bug that can cause lockups when a Partition is larger than 1TiB.

Is VFAT.VXD contained within Win-98's self-generated "master" driver (I forget the file name)? I don't see it as a separate file in this computers various c:\windows directories.

I seem to have 2 versions of that file in my archives - one with version 4.10.1998 and the other with version 4.10.2223 (10/19/2000). Is there no version 4.10.2222 for that file ???

VFAT.VXD is compressed and inserted into WINDOWS\SYSTEM\VMM32.VXD.

Version 1998 is the original Windows 98 Version
Version 2222 is the original Windows 98.SE Version.
Version 2223 is the latest Windows 98.SE Update.

I have a Patch to correct this bug.

[jaclaz]

You really need to take some time to READ the given links.
It's called "bootsector" do you think that it's code will be executed when booting?

jaclaz

[jaclaz]

wsxedcrfv, on 08 March 2011 - 09:01 AM, said:

I wouldn't have thought that every volume or partition on a drive needed it's own boot code, except for the master boot record.

Yes, as said you are missing some basics.

The actual MBR (Master Boot Record) in the "usual" form of the MS operating systems (i.e. NOT a multiboot MBR).
Has FIVE main functions:

• hold the partition table data (four entries, each 16 bytes long) that represent addresses of the partitions
  
• hold the disk signature (four bytes) on NT/2K and later systems ONLY
  
• find which of the four entries has an active state (i.e. check that either byte 0x01BE, 0x01CE, 0x01DE, 0x01EE is 0x80)
  
• check optionally that the actual partition entry marked as "active" as per above is NOT "hidden" (i.e. that it's partition type does NOT begin with 1 or 2) (some MBR code versions will not work with hidden active partitions)
  http://www.win.tue.n...on_types-1.html
  
• call the bootsector of the partition or volume makrked as active

Since it is called "Master" even semantically it implies that some "Slave" boot record must exist.

If you use a boot-loader, like grub4dos, you can "by-pass" BOTH the MBR and partition bootrecord and directly load the OS kernel, an example for DOS 7.x/8.x (a.k.a. Windows 9x/Me), create a bootable floppy running grub4dos then, you can boot your DOS/Win9x on first partition of first hard disk INDIFFERENTLY with:

chainloader (hd0)+1

the above chainloads the MBR (which chainloads the PBR, which chainloads the kernel)

root (hd0,0)
chainloader +1

the above chainloads the PBR or bootsector (which chainloads the kernel)

root (hd0,0)
chainloader /io.sys

the above directly chainloads the kernel file

BUT you need anyway some data in the MBR (the partition table data) and in the PBR ( the BPB or Bios Parameter Block), and of course the "magic bytes" 55AA.
These are detailed in the given links.

But you can try creating a FAT32 filesystem with apps like the FAT32 Formatter:
http://reboot.pro/2959/page__st__7
and you will see at a glance which parts are needed in the bootsector to actually boot.

jaclaz

This post has been edited by jaclaz: 08 March 2011 - 09:37 AM

[rloew]

wsxedcrfv, on 08 March 2011 - 07:35 AM, said:

dencorso, on 07 March 2011 - 11:08 PM, said:

It's complicated... FAT-32 always uses 3 sectors for the boot structure, however:

1) If the OS is MS-DOS,
LBA0 is the boot sector that loads IO.SYS and LBA6 is its backup;
LBA1 is the FSInfo sector and LBA7 is its backup;
LBA2 has the second part of the boot code (and is pointed to from within the code in LBA0) and LBA8 is its backup.

So LBA2 doesn't contain any data or parameters - just code? When (or under what circumstances) does any of this LBAn code get executed?

The Code is used when the particular Partition is booted from.

Quote

rloew, on 08 March 2011 - 12:00 AM, said:

VFAT.VXD is compressed and inserted into WINDOWS\SYSTEM\VMM32.VXD.

Version 1998 is the original Windows 98 Version
Version 2222 is the original Windows 98.SE Version.
Version 2223 is the latest Windows 98.SE Update.

I have a Patch to correct this bug.

Strange. In my general-purpose Win-98se folder (where I have a copy of all win-98 files, unpacked all cabs, etc) I have vfat.vxd, with a file-date 4/23/99 (the typical date for all win-98se files) - except that it has a version number of 4.10.1998.

What improvement or fix did Microsoft do with version 2223? Does it also have this 1-TB bug?

Under what circumstances does this bug manifest itself? Is it dependent or does it involve the number of clusters a volume has? IE - can it happen if the volume is less than 1-tb in size if the volume has a cluster size smaller than 32 kb?

I checked my files. You are correct. The 98SE Version is identical to the 98FE Version except for the DateStamp.
The 2223 Version (KB277628) fixes a bug in a File Date Setting function. It still has the 1TiB bug.
The bug appears in some configurations when you try to access a Directory that is located more than 1TiB into the Partition. It is not affected by the Cluster size.

[Wolfgang16]

Hello all,

I have got a Hitachi 5K3000 2TB drive. It has 3.907.029.168 sectors of 512 byte size; thats 2000,4GB or 1.907.729,1 MiB. Let me just tell you what I have done:

I formatted the HD with Paragon Partition Manager 11 under XP USB ( 1 extended Partition and 1 logical drive). Under Win98SE that worked, but the drive could not be used under DOS and scandskw and defrag reported "not enough memory", as known. Also behavior of DOS scandisk was odd. Partition Magic 8 reported errors like "wrong order" and "partition does not start at cylinder boundary", although is seems to show the correct size of the drive. Probably Paragon Partition Manager 11 uses a new kind of partitioning scheme instead of the old CHS.

After that I used Free Fdisk 1.2.1 to delete that partition and made a new one. It reported total disk space 1.907.734 MiB and the extended partition had 1.907.721 MiB. I made 2 logical drives of equal size and formated the 1st one with format.com from BHDD31. This went through in about 2 hours and the partition was fine in DOS as well as in Win98SE. scandskw and defrag worked.

Next I tried again Norton Partition Magic 8 (the DOS version). To be successful I had to delete everything with fdisk. But then PM8 accepted the disk and reported 1.907.726,6 MB, which I think should be MiB and is 243201 * 255 * 63 * 512 byte. I was even allowed to partition it and I did a small 8MB primary formated FAT, followed by an extended with logical drive but unformated. This went through and the logical drive had 1.907.718,7 MB (MiB?). The 8MB primary was usable, but a sys D: failed and when reentering PM8 it did not accept its own work: error #110: partition table number of sectors is inconsistent. Free Fdisk 1.2.1 confirmed the work which PM8 had done and reported the same size (1.907.719 MiB).

Next again Free Fdisk 1.2.1: I deleted everything and made 1 logical drive with fdisk. This time it reported 1.907.719 MiB as size of the drive, which is same as PM8, but 2MB less than it did itself in the first step. I formatted this with format.com from BHDD31. It said "formatting 1.86G" ( 1860G would be correct) and after 3 hours the % counter wrapped around, but after 4 hours format was successful. The partition seems to be fine under Win98SE (size 1,81TB).

Wolfgang

This post has been edited by Wolfgang16: 12 April 2011 - 01:55 PM

[Wolfgang16]

BTW, I posted my setup here
http://www.msfn.org/...post__p__962652

Now I figured out, what the error #110 in 16-bit version of PartitionMagic8 probably causes:

symantec said:

#110 Partition table number of sectors is inconsistent
The hard-disk partition table contains two inconsistent descriptions of the number of sectors on the hard disk. This error is serious if both DOS and another operating system use the hard disk. Because DOS uses one description and other operating systems may use the other, data loss is likely once the partition is almost full...

As far as I know there are no two descriptions of the number of sectors in the partition table. The CHS description is meaningless here. But its looks like they are still using it:
this is from the PM debug file:

Disk 1:  243201 Cylinders, 255 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000001): Access 
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables ==============================
Partition          -----Begin----      ------End-----     Start     Num
Sector     # Boot   Cyl Head Sect  FS   Cyl Head Sect     Sect      Sects
---------- - ----  ---- ---- ----  --  ---- ---- ----  ---------- ----------
         0 0 00   [   0    1    1] 0C [1023  254   63]         63 3907024002 [Large Drive Placeholders]
                      0    1    1     46592  254   63                         Actual Values
Error #110: Number of sectors in partition is inconsistent.
  ucSectors   = 3907024002
  end - begin = 748516482

Obviously PM8 takes the "Number of Sectors" and calculates:
3907024002 + 63 = 63 * 255 * 243201
This is stored in 16-bit variables which results in
243201 - 3 * 65536 = 46593
This is displayed as "Actual Value" of Cyl. Now it calculates back:
46593 * 255 * 63 -63 = 748516482
This is now compared to the initial value which is wrong and gives error #110.

So PM8 only works with partitions up to 539GB. I can confirm that PM8 works with 500GB partitions.

The problem is also discussed here:
http://www.hwkb.com/...rs-in-partition
There is it said that the 32-bit version of PM8 does not have this problem.

I like the GUI of PM8, it prevents me from entering something wrong. So its a pity that this stupid and senseless check restricts the usability of PM8. Nevertheless I was able to use it to partition my drive. I have now a small 8MB hidden primary and the big rest is divided into 2 logical drives of equal size, so that I am able to use scandskw. PM8 rejected to format FAT32, so I did it with fat32format under XP.

So I have 2 questions to the community

1. I used a partitioning program which has obviously problems with big drives, but I checked the partitions with Free Fdisk, Win XP partitioner, Paragon Partition Manager 11 and Easeus Partition Master 8. None of them reported an error. Is this safe now or can there still be a pitfall?

2. Initially I tended to prefer a modern partitioner, but the negative experience with Paragon Partiton Manger 11 let me hesitate. Do you think that modern partitioners can generate partitions which look faulty under DOS?

This post has been edited by Wolfgang16: 15 April 2011 - 01:48 PM