Opened 9 years ago

Closed 3 years ago

Last modified 16 months ago

#6301 closed bug (fixed)

DriveSetup writes MBR inconsistent with anyboot image.

Reported by: preroll Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/DriveSetup Version: R1/alpha2
Keywords: MBR boot CHS bits Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: x86

Description

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

Attachments (1)

intel-partitioning-system-unused-chs.diff (1.6 KB ) - added by bonefish 9 years ago.
patch for setting CHS to 0xffffff as suggested

Download all attachments as: .zip

Change History (12)

by bonefish, 9 years ago

patch for setting CHS to 0xffffff as suggested

comment:2 by bonefish, 9 years ago

Has a Patch: set

comment:3 by bonefish, 9 years ago

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

comment:4 by stippi, 9 years ago

starsseed, were you able to test the attached patch?

comment:5 by starsseed, 9 years ago

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).

in reply to:  5 comment:6 by preroll, 9 years ago

Replying to starsseed:

Preroll, did you test the patch ?

Sorry, I have no experience with patches.

in reply to:  5 ; comment:7 by bonefish, 9 years ago

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?

in reply to:  7 comment:8 by starsseed, 9 years ago

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
totalSectorsTotal data sectors present in the disk image
cylindersNumber of cylinders present on the disk
headsNumber of heads present on the disk
sectorsPerTrackSectors per track on the disk
cylinderTimesHeadCylinders 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 partitioning 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
Last edited 9 years ago by starsseed (previous) (diff)

comment:9 by scottmc, 8 years ago

Blocking: 7665 added

comment:10 by pulkomandy, 3 years ago

Resolution: fixed
Status: newclosed

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.

comment:11 by waddlesplash, 16 months ago

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.