DriveSetup writes MBR inconsistent with anyboot image.

[preroll]

Suspect 'DriveSetup' changes MBR partition entry (offsets 447,448,449), causing some BIOS's not to boot.

Comparison of MBR partition table (from offset 446..)

---

Original IMG (r1alpha2-anyboot image) (boots)

80 FF

FF FF EB FF FF FF 00 20 00 00 00 50 14 00 00 00

---

After DriveSetup+Installer (no-boot)

80 00

00 00 EB 00 00 00 40 00 00 00 00 A8 FA 00 00 00

---

Original IMG is using "FF FF FF" for CHS data, while DriveSetup is using "00 00 00".

Re-creation: Write IMG to USB drive. Delete 650mb partition Create and Initalise an active partition to use the whole drive. Install into created partition (using 'Installer'). Compare the MBRs.

Suggestion: Use "FF FF FF", as more BIOS types seem to agree with this, or better still calculate the actual CHS bits.

Possibly Related: #5980, #5595

[starsseed]

Preroll's description in the forum
​http://www.haiku-os.org/community/forum/usb_boot_installer#comment-16308

[bonefish]

patch for setting CHS to 0xffffff as suggested

[bonefish]

Added a patch that should set the CHS fields to 0xffffff as suggested. Don't have the time/motivation to test it, ATM.

[stippi]

starsseed, were you able to test the attached patch?

[starsseed]

haiku_loader does not work on my laptop (see the bug #4408 #5539 #5696 #5720) so, I can't test on it. Neither on my desktop system whom BIOS doesn't care about CHS informations...

But I remember having problems to create a valid MBR/partition-table for my USB key, and I never completely understood why! (now I create the MBR and the partition from windows and copy the boot-code area from an AnyBoot-image with dd)

Preroll, did you test the patch ?

@Bonefish
Note that:

• FF FF FF implies a disks with UUID partition table (EFI) then EF FF FF would be better
• since DriveSetup creates the first partition at sector CHS={01 02 00} (i.e. Cylinder=0/Head=1/sector=2 or LBA=40) it seems it does not take care about the disk geometry. I think it's not correct : the 1st partition should be aligned on the 1st sector (2nd,3rd,4th partition should be aligned on head*sector - 1st sector/Head 0).

[preroll]

Replying to starsseed:

Preroll, did you test the patch ?

Sorry, I have no experience with patches.

[bonefish]

Replying to starsseed:

@Bonefish
Note that:

• FF FF FF implies a disks with UUID partition table (EFI) then EF FF FF would be better

Where have you got this information from? I've never heard of this.

• since DriveSetup creates the first partition at sector CHS={01 02 00} (i.e. Cylinder=0/Head=1

/sector=2 or LBA=40) it seems it does not take care about the disk geometry. I think it's not correct : the 1st partition should be aligned on the 1st sector (2nd,3rd,4th partition should be aligned on head*sector - 1st sector/Head 0).

I believe we don't even know the actual disk geometry at this point, let alone that it probably cannot be represented with the limited CHS scheme anyway. Does anyone even care about these alignments still?

[starsseed]

Replying to bonefish:

Replying to starsseed:

@Bonefish
Note that:

• FF FF FF implies a disks with UUID partition table (EFI) then EF FF FF would be better

Where have you got this information from? I've never heard of this.

​http://en.wikipedia.org/wiki/Master_boot_record#cite_note-8

• since DriveSetup creates the first partition at sector CHS={01 02 00} (i.e. Cylinder=0/Head=1

/sector=2 or LBA=40) it seems it does not take care about the disk geometry. I think it's not correct : the 1st partition should be aligned on the 1st sector (2nd,3rd,4th partition should be aligned on head*sector - 1st sector/Head 0).

I believe we don't even know the actual disk geometry at this point, let alone that it probably cannot be represented with the limited CHS scheme anyway. Does anyone even care about these alignments still?

However, it greatly affects performances.

CHS Calculation

Variables in CHS calculation	Description
totalSectors	Total data sectors present in the disk image
cylinders	Number of cylinders present on the disk
heads	Number of heads present on the disk
sectorsPerTrack	Sectors per track on the disk
cylinderTimesHead	Cylinders x heads

                    C      H     S
if (totalSectors > 65535 * 16 * 255)
{
   totalSectors = 65535 * 16 * 255;
}

if (totalSectors >= 65535 * 16 * 63)
{
   sectorsPerTrack = 255;
   heads = 16;
   cylinderTimesHeads = totalSectors / sectorsPerTrack;
}
else
{
   sectorsPerTrack = 17; 
   cylinderTimesHeads = totalSectors / sectorsPerTrack;

   heads = (cylinderTimesHeads + 1023) / 1024;
      
   if (heads < 4)
   {
      heads = 4;
   }
   if (cylinderTimesHeads >= (heads * 1024) || heads > 16)
   {
      sectorsPerTrack = 31;
      heads = 16;
      cylinderTimesHeads = totalSectors / sectorsPerTrack;	
   }
   if (cylinderTimesHeads >= (heads * 1024))
   {
      sectorsPerTrack = 63;
      heads = 16;
      cylinderTimesHead = totalSectors / sectorsPerTrack;
   }
}
cylinders = cylinderTimesHead / heads;

here are the rules used by some partitionning tools.

1. If the first sector of the cylinder is a partition table sector, then the rest of the track is unused, and the partition starts with the the next track. This applies to sector 0 (the MBR) and the partition table sectors preceding logical partitions.
2. Otherwise, the partition starts at the first sector of the cylinder. Also the extended partition starts at a cylinder boundary

[pulkomandy]

Patch applied in hrev50577. It matches what I read at ​http://wiki.osdev.org/Partition_Table:

• For drives bigger than 8GB, generally the CHS fields are set to Cylinder = 1023, Head = 254 or 255, Sector = 63 -- which is considered an invalid setting.
• Any other illegal value (CHS Sector = 0 or Total Sectors = 0) may also indicate an unused entry.