From sjr@home.net  Tue Aug 15 20:55:01 2000
Return-Path: <sjr@home.net>
Received: from cc158233-a.catv1.md.home.com (cc158233-a.catv1.md.home.com [24.3.25.17])
	by hub.freebsd.org (Postfix) with ESMTP id 951C237BB40
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 15 Aug 2000 20:54:59 -0700 (PDT)
	(envelope-from sjr@home.net)
Received: (from sjr@localhost)
	by cc158233-a.catv1.md.home.com (8.9.3/8.9.3) id XAA00784;
	Tue, 15 Aug 2000 23:54:53 -0400 (EDT)
	(envelope-from sjr)
Message-Id: <200008160354.XAA00784@cc158233-a.catv1.md.home.com>
Date: Tue, 15 Aug 2000 23:54:53 -0400 (EDT)
From: sjr@home.com
Sender: sjr@home.net
Reply-To: sjr@home.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: fdisk doesn't handle LBA correctly
X-Send-Pr-Version: 3.2

>Number:         20633
>Category:       bin
>Synopsis:       fdisk(8) doesn't handle LBA correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 15 21:00:01 PDT 2000
>Closed-Date:    Fri Jan 28 08:21:39 UTC 2011
>Last-Modified:  Fri Jan 28 08:21:39 UTC 2011
>Originator:     Stephen J. Roznowski
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
>Environment:

	

>Description:

I'm not sure if this is related to PR 14974...

When I run fdisk, I get:

	******* Working on device /dev/ad0 *******
	parameters extracted from in-core disklabel are:
	cylinders=3720 heads=255 sectors/track=63 (16065 blks/cyl)

	Figures below won't work with BIOS for partitions not in cyl 1
	parameters to be used for BIOS calculations are:
	cylinders=3720 heads=255 sectors/track=63 (16065 blks/cyl)

	Media sector size is 512
	Warning: BIOS sector numbering starts with sector 1
	Information from DOS bootblock is:
	The data for partition 1 is:
	sysid 12,(DOS or Windows 95 with 32 bit FAT, LBA)
	    start 63, size 8385867 (4094 Meg), flag 0
		beg: cyl 0/ sector 1/ head 1;
		end: cyl 521/ sector 63/ head 254
	The data for partition 2 is:
	sysid 165,(FreeBSD/NetBSD/386BSD)
	    start 8385930, size 34604010 (16896 Meg), flag 80 (active)
		beg: cyl 522/ sector 1/ head 0;
		end: cyl 1022/ sector 63/ head 254
	The data for partition 3 is:
	sysid 12,(DOS or Windows 95 with 32 bit FAT, LBA)
	    start 51375870, size 8385930 (4094 Meg), flag 0
		beg: cyl 1022/ sector 1/ head 0;
		end: cyl 1022/ sector 63/ head 254
	The data for partition 4 is:
	<UNUSED>

Except for partition #1, these values are wrong. They should be

	1:    0/1/1  521/63/254
	2:  522/1/0 2675/63/254
	3: 3198/1/0 3719/63/254

As I understand it, for partition types 0xC, 0xE, 0xF (12, 14, 15)
LBA is used and the C/S/H entries are ignored.

fdisk should be modified to do the correct thing depending on the
partition type.

>How-To-Repeat:

	

>Fix:

	


>Release-Note:
>Audit-Trail:

From: John Baldwin <jhb@pike.osd.bsdi.com>
To: freebsd-gnats-submit@FreeBSD.org, sjr@home.com
Cc:  
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Fri, 25 Aug 2000 02:05:42 -0700 (PDT)

 Your analysis is not quite correct.  The problem is that the MBR format
 cannot indicate a cylinder higher than 1023 because there simply aren't
 enough bits.  Therefore, when a geometry specification goes beyond
 the 1023rd cylinder, a special value of '0xffffff' is used in the partition
 table entry, which indicates that the starting LBA and size items must be
 used for a given entry.  This special value translates into the values you see
 in your fdisk output.
 
 -- 
 
 John Baldwin <jhb@bsdi.com> -- http://www.FreeBSD.org/~jhb/
 PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
 "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
 
Responsible-Changed-From-To: freebsd-bugs->jhb 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Fri Aug 25 02:16:21 PDT 2000 
Responsible-Changed-Why:  
Let's see if we can pin this on John without getting 
our hands slapped. :-) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20633 
State-Changed-From-To: open->closed 
State-Changed-By: jhb 
State-Changed-When: Sat Mar 10 17:44:12 PST 2001 
State-Changed-Why:  
The described behavior is not a bug but just a quirk of the PC BIOS. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20633 
State-Changed-From-To: closed->open 
State-Changed-By: jhb 
State-Changed-When: Fri Mar 16 11:14:36 PST 2001 
State-Changed-Why:  
- While the raw dump of the C/H/S by fdisk may be technically correct, it 
is not very aesthetically pleasing.   The originator has suggested 
looking at porting over the fdisk(8) command from NetBSD or OpenBSD or 
parts of it to improve the UI of fdisk(8). 
- Being tied up with SMPng, I don't have time to work on this right now, so 
I've assigned it back to bugs. 


Class-Changed-From-To: sw-bug->change-request 
Class-Changed-By: jhb 
Class-Changed-When: Fri Mar 16 11:14:36 PST 2001 
Class-Changed-Why:  
This is now more of a feature change request than an actual bug. 


Responsible-Changed-From-To: jhb->bugs 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Fri Mar 16 11:14:36 PST 2001 
Responsible-Changed-Why:  
Kicking this back over to bugs as I don't have time for fdisk right now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20633 
Responsible-Changed-From-To: bugs->freebsd-bugs 
Responsible-Changed-By: billf 
Responsible-Changed-When: Fri Mar 16 22:45:57 PST 2001 
Responsible-Changed-Why:  
correct mailing list 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20633 

From: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
To: freebsd-gnats-submit@FreeBSD.org, sjr@home.com
Cc:  
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Fri, 16 Aug 2002 16:56:01 +0400

 	Hi, if I understand what jhb said in audit trail, following patch
 should solve the issue. Stephen, if it still bothers you, could you try
 it?
 
 --- sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:24:27 2002
 +++ sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:33:28 2002
 @@ -468,13 +468,21 @@
  		part_mb,
  		partp->dp_flag,
  		partp->dp_flag == ACTIVE ? " (active)" : "");
 -	printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n"
 -		,DPCYL(partp->dp_scyl, partp->dp_ssect)
 -		,partp->dp_shd
 -		,DPSECT(partp->dp_ssect)
 -		,DPCYL(partp->dp_ecyl, partp->dp_esect)
 -		,partp->dp_ehd
 -		,DPSECT(partp->dp_esect));
 +	/* 
 +	 * if C/H/S of start or end are all set to 0xff, then C/H/S don't have
 +	 * enough bits to hold the address, and one should use LBA instead.
 +	 */
 +	if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff || 
 +		partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff || 
 +		partp->dp_esect != 0xff || partp->dp_ehd != 0xff))
 +		printf("\tbeg: cyl %d/ head %d/ sector %d;\n"
 +			"\tend: cyl %d/ head %d/ sector %d\n"
 +			,DPCYL(partp->dp_scyl, partp->dp_ssect)
 +			,partp->dp_shd
 +			,DPSECT(partp->dp_ssect)
 +			,DPCYL(partp->dp_ecyl, partp->dp_esect)
 +			,partp->dp_ehd
 +			,DPSECT(partp->dp_esect));
  }
  
  
 			Sinceherely yours, Artem 'Zazoobr' Ignatjev.

From: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
To: Bruce Evans <bde@zeta.org.au>, freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Fri, 16 Aug 2002 22:42:35 +0400

 On Sat, Aug 17, 2002 at 03:56:57AM +1000, Bruce Evans wrote:
 > On Fri, 16 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
 > >  	Hi, if I understand what jhb said in audit trail, following patch
 > >  should solve the issue. Stephen, if it still bothers you, could you try
 > >  it?
 > >
 > >  --- sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:24:27 2002
 > >  +++ sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:33:28 2002
 > >  @@ -468,13 +468,21 @@
 [skip]
 > >  -	printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n"
 [skip]
 > >  +	/*
 > >  +	 * if C/H/S of start or end are all set to 0xff, then C/H/S don't have
 > >  +	 * enough bits to hold the address, and one should use LBA instead.
 > >  +	 */
 > >  +	if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff ||
 > >  +		partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff ||
 > >  +		partp->dp_esect != 0xff || partp->dp_ehd != 0xff))
 > >  +		printf("\tbeg: cyl %d/ head %d/ sector %d;\n"
 [skip]
 > 
 > Fdisk should print these values, at least optionally, since they are needed
 > for debugging.  The magic values might be non-magic on old systems.
 Debugging WHAT? And, I can hardly imagine such a situation inside hard
 drives & slice tables.
 > Also, the usual magic number of cylinders seems to be 1022, not 1023.
 I disagree. Now i'm hacking fdisk to work with extended slices, it can
 now dump partition table of the whole disk, since this inability dove me
 mad when I was installing FreeBSD into extended (there was another issue
 to make it boot :-) ), when i'll finish it, I'll send the proposed
 sources/patches to -hackers, also I hope I make boot2 more friendly to
 extended slices (I've got already hack for boot1 to allow booting from
 bootmanagers ala ntloader). 
 Take a look at the dump (I've cut all entries regarding extendeds below
 the top-level slicetable, since them all take space, but are of no
 interest now)
 
 Script started on Fri Aug 16 22:23:06 2002
 ******* Working on device /dev/ad4 *******
 parameters extracted from in-core disklabel are:
 cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
 
 Figures below won't work with BIOS for partitions not in cyl 1
 parameters to be used for BIOS calculations are:
 cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
 
 Media sector size is 512
 Warning: BIOS sector numbering starts with sector 1
 Information from DOS bootblock is:
 The data for partition 1 is:
 sysid 6 (Primary 'big' DOS (> 32MB)),
     start 63, size 2088387 (1019 Meg), flag 0
 	beg: cyl 0/ head 1/ sector 1;
 	end: cyl 129/ head 254/ sector 63
 The data for partition 2 is:
 sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
     start 2088450, size 8385930 (4094 Meg), flag 80 (active)
 	beg: cyl 130/ head 0/ sector 1;
 	end: cyl 651/ head 254/ sector 63
 The data for partition 3 is:
 sysid 131 (Linux filesystem),
     start 10474380, size 4192965 (2047 Meg), flag 0
 	beg: cyl 652/ head 0/ sector 1;
 	end: cyl 912/ head 254/ sector 63
 The data for partition 4 is:
 sysid 15 (Extended DOS, LBA),
     start 14667345, size 105435855 (51482 Meg), flag 0
 	beg: cyl 913/ head 0/ sector 1;
 	end: cyl 1023/ head 254/ sector 63
 The data for partition 5 is:
 sysid 130 (Linux swap or Solaris x86),
     start 14667408, size 256977 (125 Meg), flag 0
 	beg: cyl 913/ head 1/ sector 1;
 	end: cyl 928/ head 254/ sector 63
 The data for partition 7 is:
 sysid 131 (Linux filesystem),
     start 14924448, size 16771797 (8189 Meg), flag 0
 	beg: cyl 929/ head 1/ sector 1;
 	end: cyl 1023/ head 254/ sector 63
 The data for partition 9 is:
 sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
     start 31696308, size 40965687 (20002 Meg), flag 0
 	beg: cyl 1023/ head 1/ sector 1;
 	end: cyl 1023/ head 254/ sector 63
 The data for partition 11 is:
 sysid 12 (FAT-32, LBA),
     start 72662058, size 7389837 (3608 Meg), flag 0
 	beg: cyl 1023/ head 1/ sector 1;
 	end: cyl 1023/ head 254/ sector 63
 The data for partition 13 is:
 sysid 165 (FreeBSD/NetBSD/386BSD),
     start 80051958, size 8401932 (4102 Meg), flag 0
 	beg: cyl 1023/ head 254/ sector 63;
 	end: cyl 1023/ head 254/ sector 63
 The data for partition 15 is:
 sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
     start 88453953, size 25398702 (12401 Meg), flag 0
 	beg: cyl 1023/ head 1/ sector 1;
 	end: cyl 1023/ head 254/ sector 63
 Script done on Fri Aug 16 22:23:06 2002
 
 A-ha! Better see once, than hear many times: magic value for start is
 1023/1/1, and for end is 1023/254/63, but note my FreeBSD slice - it was
 created using linux fdisk, but even these strange values works ok.
 
 > Writing the correct magic numbers is more interesting.  fdisk(8) doesn't
 > support it directly.  You may have to change the C/H/S values to the magic
 > ones manually.
  Is there any papers on the subject? All my knowledge was obtained experimentally, watching how my dad revives dead hds....
  It looks like the magic is cyl=1023, regardless of h/s values...
 			Sinceherely yours, Artem 'Zazoobr' Ignatjev.

From: Bruce Evans <bde@zeta.org.au>
To: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Sun, 18 Aug 2002 02:12:45 +1000 (EST)

 On Fri, 16 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
 
 > On Sat, Aug 17, 2002 at 03:56:57AM +1000, Bruce Evans wrote:
 > > On Fri, 16 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
 > > >  	Hi, if I understand what jhb said in audit trail, following patch
 > > >  should solve the issue. Stephen, if it still bothers you, could you try
 > > >  it?
 > > >
 > > >  --- sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:24:27 2002
 > > >  +++ sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:33:28 2002
 > > >  @@ -468,13 +468,21 @@
 > [skip]
 > > >  -	printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n"
 > [skip]
 > > >  +	/*
 > > >  +	 * if C/H/S of start or end are all set to 0xff, then C/H/S don't have
 > > >  +	 * enough bits to hold the address, and one should use LBA instead.
 > > >  +	 */
 > > >  +	if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff ||
 > > >  +		partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff ||
 > > >  +		partp->dp_esect != 0xff || partp->dp_ehd != 0xff))
 > > >  +		printf("\tbeg: cyl %d/ head %d/ sector %d;\n"
 > [skip]
 > >
 > > Fdisk should print these values, at least optionally, since they are needed
 > > for debugging.  The magic values might be non-magic on old systems.
 > Debugging WHAT? And, I can hardly imagine such a situation inside hard
 > drives & slice tables.
 
 Debugging hard disk tables and slice tables.  I do it routinely.  It
 can be important to look at the raw data, but the dp_scyl...dp_ehd
 data is a little too raw.
 
 > > Also, the usual magic number of cylinders seems to be 1022, not 1023.
 > I disagree. Now i'm hacking fdisk to work with extended slices, it can
 
 We don't get to decide.  There are braindamaged conventions about this
 to give compatibility with broken BIOSes and broken fdisks.
 
 Actually, 1023 is most magic (it is what the kernel expects), but the
 data in the PR shows that 1022 is magic too.  The magic 0xfe in the
 kernel is for the ending head number.  It can be important not to use
 a starting or ending head number of 255 (== a head count of 256) because
 some broken BIOSes crash on it, and there are now conventions that
 prohibit using it.
 
 > Take a look at the dump (I've cut all entries regarding extendeds below
 > the top-level slicetable, since them all take space, but are of no
 > interest now)
 >
 > Script started on Fri Aug 16 22:23:06 2002
 > ******* Working on device /dev/ad4 *******
 > parameters extracted from in-core disklabel are:
 > cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
 >
 > Figures below won't work with BIOS for partitions not in cyl 1
 > parameters to be used for BIOS calculations are:
 > cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl)
 >
 > Media sector size is 512
 > Warning: BIOS sector numbering starts with sector 1
 > Information from DOS bootblock is:
 > The data for partition 1 is:
 > sysid 6 (Primary 'big' DOS (> 32MB)),
 >     start 63, size 2088387 (1019 Meg), flag 0
 > 	beg: cyl 0/ head 1/ sector 1;
 > 	end: cyl 129/ head 254/ sector 63
 > The data for partition 2 is:
 > sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
 >     start 2088450, size 8385930 (4094 Meg), flag 80 (active)
 > 	beg: cyl 130/ head 0/ sector 1;
 > 	end: cyl 651/ head 254/ sector 63
 > The data for partition 3 is:
 > sysid 131 (Linux filesystem),
 >     start 10474380, size 4192965 (2047 Meg), flag 0
 > 	beg: cyl 652/ head 0/ sector 1;
 > 	end: cyl 912/ head 254/ sector 63
 > The data for partition 4 is:
 > sysid 15 (Extended DOS, LBA),
 >     start 14667345, size 105435855 (51482 Meg), flag 0
 > 	beg: cyl 913/ head 0/ sector 1;
 > 	end: cyl 1023/ head 254/ sector 63
 > The data for partition 5 is:
 > sysid 130 (Linux swap or Solaris x86),
 >     start 14667408, size 256977 (125 Meg), flag 0
 > 	beg: cyl 913/ head 1/ sector 1;
 > 	end: cyl 928/ head 254/ sector 63
 > The data for partition 7 is:
 > sysid 131 (Linux filesystem),
 >     start 14924448, size 16771797 (8189 Meg), flag 0
 > 	beg: cyl 929/ head 1/ sector 1;
 > 	end: cyl 1023/ head 254/ sector 63
 > The data for partition 9 is:
 > sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
 >     start 31696308, size 40965687 (20002 Meg), flag 0
 > 	beg: cyl 1023/ head 1/ sector 1;
 > 	end: cyl 1023/ head 254/ sector 63
 > The data for partition 11 is:
 > sysid 12 (FAT-32, LBA),
 >     start 72662058, size 7389837 (3608 Meg), flag 0
 > 	beg: cyl 1023/ head 1/ sector 1;
 > 	end: cyl 1023/ head 254/ sector 63
 > The data for partition 13 is:
 > sysid 165 (FreeBSD/NetBSD/386BSD),
 >     start 80051958, size 8401932 (4102 Meg), flag 0
 > 	beg: cyl 1023/ head 254/ sector 63;
 > 	end: cyl 1023/ head 254/ sector 63
 > The data for partition 15 is:
 > sysid 7 (OS/2 HPFS, NTFS, QNX-2 (16 bit)),
 >     start 88453953, size 25398702 (12401 Meg), flag 0
 > 	beg: cyl 1023/ head 1/ sector 1;
 > 	end: cyl 1023/ head 254/ sector 63
 > Script done on Fri Aug 16 22:23:06 2002
 
 Seems reasonable.  It shows all of the magic beg and end values, because
 the most magic one (all 0xff's) is so magic that it is never used :-).
 
 > A-ha! Better see once, than hear many times: magic value for start is
 > 1023/1/1, and for end is 1023/254/63, but note my FreeBSD slice - it was
 > created using linux fdisk, but even these strange values works ok.
 
 Linux fdisk apparently hasn't been dumbed down to follow current
 conventions.  It still uses a second-or third-best convention for the
 "beg" values.  These values should be as non-physical as possible so
 that they don't get used by old BIOSes and are seen to be conventional
 by most fdisks.  The best values are probably 1023/255/63 for "beg"
 and 1023/actual_heads/actual_sectors for "end".
 
 > > Writing the correct magic numbers is more interesting.  fdisk(8) doesn't
 > > support it directly.  You may have to change the C/H/S values to the magic
 > > ones manually.
 >  Is there any papers on the subject? All my knowledge was obtained experimentally, watching how my dad revives dead hds....
 >  It looks like the magic is cyl=1023, regardless of h/s values...
 
 I haven't kept up with the current conventions except for following the
 changes in the FreeBSD boot loader and MBR-reading code to keep down^Wup
 with them.  Search the web.  10 year ago, one of the best documents was
 by Hale Landis.  I searched for "hale landis mbr" and found something
 saying that "Hale no longer attempts to keep up with all the silly
 and stupid things that OS designers are doing in partition tables" :-).
 It still says that there are no standards.  There is a new standard
 named something like EFI GPT.
 
 Bruce
 

From: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
To: Bruce Evans <bde@zeta.org.au>, freebsd-gnats-submit@freebsd.org
Cc: freebsd-hackers@freebsd.org
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Sat, 17 Aug 2002 21:56:24 +0400

 On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote:
 >>>>  	Hi, if I understand what jhb said in audit trail, following patch
 >>>>  should solve the issue. Stephen, if it still bothers you, could you try
 >>>>  it?
 >>>>
 >>>>  --- sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:24:27 2002
 >>>>  +++ sbin/i386/fdisk/fdisk.c	Fri Aug 16 16:33:28 2002
 >>>>  @@ -468,13 +468,21 @@
 >> [skip]
 >>>>  -	printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n"
 >> [skip]
 >>>>  +	/*
 >>>>  +	 * if C/H/S of start or end are all set to 0xff, then C/H/S don't have
 >>>>  +	 * enough bits to hold the address, and one should use LBA instead.
 >>>>  +	 */
 >>>>  +	if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff ||
 >>>>  +		partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff ||
 >>>>  +		partp->dp_esect != 0xff || partp->dp_ehd != 0xff))
 >>>>  +		printf("\tbeg: cyl %d/ head %d/ sector %d;\n"
 >> [skip]
 >>>
 >>> Fdisk should print these values, at least optionally, since they are needed
 >>> for debugging.  The magic values might be non-magic on old systems.
 >> Debugging WHAT? And, I can hardly imagine such a situation inside hard
 >> drives & slice tables.
 > 
 > Debugging hard disk tables and slice tables.  I do it routinely.  It
 > can be important to look at the raw data, but the dp_scyl...dp_ehd
 > data is a little too raw.
 Ok, so we must add option to fdisk(8) to print CHS?
 And, BTW, does CHS makes sense inside an extended slices?
 >>> Also, the usual magic number of cylinders seems to be 1022, not 1023.
 >> I disagree. Now i'm hacking fdisk to work with extended slices, it can
 > 
 > We don't get to decide.  There are braindamaged conventions about this
 > to give compatibility with broken BIOSes and broken fdisks.
 > 
 > Actually, 1023 is most magic (it is what the kernel expects), but the
 > data in the PR shows that 1022 is magic too.  The magic 0xfe in the
 > kernel is for the ending head number.  It can be important not to use
 > a starting or ending head number of 255 (== a head count of 256) because
 > some broken BIOSes crash on it, and there are now conventions that
 > prohibit using it.
 
 Maybe we should take as magic cyls >1021? And where can one read all
 this conventions?
 >> Take a look at the dump (I've cut all entries regarding extendeds below
 >> the top-level slicetable, since them all take space, but are of no
 >> interest now)
 >>
 >> Script started on Fri Aug 16 22:23:06 2002
 [skip]
 >> Information from DOS bootblock is:
 >> The data for partition 1 is:
 >> sysid 6 (Primary 'big' DOS (> 32MB)),
 >>     start 63, size 2088387 (1019 Meg), flag 0
 >> 	beg: cyl 0/ head 1/ sector 1;
 >> 	end: cyl 129/ head 254/ sector 63
 [skip]
 >> The data for partition 4 is:
 >> sysid 15 (Extended DOS, LBA),
 >>     start 14667345, size 105435855 (51482 Meg), flag 0
 >> 	beg: cyl 913/ head 0/ sector 1;
 >> 	end: cyl 1023/ head 254/ sector 63
 >> The data for partition 5 is:
 >> sysid 130 (Linux swap or Solaris x86),
 >>     start 14667408, size 256977 (125 Meg), flag 0
 >> 	beg: cyl 913/ head 1/ sector 1;
 >> 	end: cyl 928/ head 254/ sector 63
 Looks like there is no adjustment for CHS, while there are wierd
 adjustment requirements for LBA
 >> The data for partition 7 is:
 >> sysid 131 (Linux filesystem),
 >>     start 14924448, size 16771797 (8189 Meg), flag 0
 >> 	beg: cyl 929/ head 1/ sector 1;
 >> 	end: cyl 1023/ head 254/ sector 63
 [skip]
 >> The data for partition 13 is:
 >> sysid 165 (FreeBSD/NetBSD/386BSD),
 >>     start 80051958, size 8401932 (4102 Meg), flag 0
 >> 	beg: cyl 1023/ head 254/ sector 63;
 >> 	end: cyl 1023/ head 254/ sector 63
 >> Script done on Fri Aug 16 22:23:06 2002
 > 
 > Seems reasonable.  It shows all of the magic beg and end values, because
 > the most magic one (all 0xff's) is so magic that it is never used :-).
 and how  translates that value to CHS? Guess 1023/255/63?
 > 
 >> A-ha! Better see once, than hear many times: magic value for start is
 >> 1023/1/1, and for end is 1023/254/63, but note my FreeBSD slice - it was
 >> created using linux fdisk, but even these strange values works ok.
 > 
 > Linux fdisk apparently hasn't been dumbed down to follow current
 > conventions.  It still uses a second-or third-best convention for the
 > "beg" values.  These values should be as non-physical as possible so
 > that they don't get used by old BIOSes and are seen to be conventional
 > by most fdisks.  The best values are probably 1023/255/63 for "beg"
 > and 1023/actual_heads/actual_sectors for "end".
 > 
 >>> Writing the correct magic numbers is more interesting.  fdisk(8) doesn't
 >>> support it directly.  You may have to change the C/H/S values to the magic
 >>> ones manually.
 >>  Is there any papers on the subject? All my knowledge was obtained experimentally, watching how my dad revives dead hds....
 >>  It looks like the magic is cyl=1023, regardless of h/s values...
 > 
 > I haven't kept up with the current conventions except for following the
 > changes in the FreeBSD boot loader and MBR-reading code to keep down^Wup
 > with them.  Search the web.  10 year ago, one of the best documents was
 > by Hale Landis.  I searched for "hale landis mbr" and found something
 > saying that "Hale no longer attempts to keep up with all the silly
 > and stupid things that OS designers are doing in partition tables" :-).
 > It still says that there are no standards.  There is a new standard
 > named something like EFI GPT.
 Any url? Or `google knows'? ;-)
 I suppose, that it will be better to follow the linux' fdisk..
 Could you please look at http://memphis.mephi.ru/~timon/fdisk/ (and http://memphis.mephi.ru/~timon at all ;-) since you'll need a patch from there  or manually define DOSPTYP_EXTX if you'll try to compile it )?
 And, one more : I suggest this discussion should go to -hackers...
 (Adding a CC there...)
 			Sinceherely yours, Artem 'Zazoobr' Ignatjev.

From: Bruce Evans <bde@zeta.org.au>
To: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
Cc: freebsd-gnats-submit@freebsd.org, <freebsd-hackers@freebsd.org>
Subject: Re: bin/20633: fdisk doesn't handle LBA correctly
Date: Sun, 18 Aug 2002 07:45:23 +1000 (EST)

 On Sat, 17 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
 
 > On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote:
 > >> [skip]
 > >>>
 > >>> Fdisk should print these values, at least optionally, since they are needed
 > >>> for debugging.  The magic values might be non-magic on old systems.
 > >> Debugging WHAT? And, I can hardly imagine such a situation inside hard
 > >> drives & slice tables.
 > >
 > > Debugging hard disk tables and slice tables.  I do it routinely.  It
 > > can be important to look at the raw data, but the dp_scyl...dp_ehd
 > > data is a little too raw.
 > Ok, so we must add option to fdisk(8) to print CHS?
 
 If we displayed suppressed the existing display for cases where we know
 it is bogus, then there should be an option to display it for these cases.
 
 > And, BTW, does CHS makes sense inside an extended slices?
 
 I think so, since boot loaders might use at least the starting C/H/S if
 there are any boot loaders that support booting from logical drives in
 extended partitions (I think lilo can).  Using them might even work for
 cylinders below 1024.
 
 > > ...
 > > Actually, 1023 is most magic (it is what the kernel expects), but the
 > > data in the PR shows that 1022 is magic too.  The magic 0xfe in the
 > > kernel is for the ending head number.  It can be important not to use
 > > a starting or ending head number of 255 (== a head count of 256) because
 > > some broken BIOSes crash on it, and there are now conventions that
 > > prohibit using it.
 >
 > Maybe we should take as magic cyls >1021?
 
 Don't assume much when displaying magic values, but only write values that
 satisfy current conventions.
 
 > And where can one read all
 > this conventions?
 
 google :-).
 
 > [skip]
 > >> The data for partition 13 is:
 > >> sysid 165 (FreeBSD/NetBSD/386BSD),
 > >>     start 80051958, size 8401932 (4102 Meg), flag 0
 > >> 	beg: cyl 1023/ head 254/ sector 63;
 > >> 	end: cyl 1023/ head 254/ sector 63
 > >> Script done on Fri Aug 16 22:23:06 2002
 > >
 > > Seems reasonable.  It shows all of the magic beg and end values, because
 > > the most magic one (all 0xff's) is so magic that it is never used :-).
 
 > and how  translates that value to CHS? Guess 1023/255/63?
 
 Something like "beg: [invalid]" for 1023/255/63, and "beg: [not used]
 for 1023/254/63.
 
 > I suppose, that it will be better to follow the linux' fdisk..
 
 > Could you please look at http://memphis.mephi.ru/~timon/fdisk/ (and http://memphis.mephi.ru/~timon at all ;-) since you'll need a patch from there  or manually define DOSPTYP_EXTX if you'll try to compile it )?
 
 Not sure if I have time to look at the details.
 
 Bruce
 

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org, sjr@home.com
Cc:  
Subject: Re: bin/20633: fdisk(8) doesn't handle LBA correctly
Date: Sun, 12 Sep 2010 11:50:34 +0100

 fdisk is more or less obsolete now that gpart has been introduced that
 can handle all the modern partition tables as well as MBR. We should
 probably check that gpart writes the correct magic values too, though.
 
 -- 
 Bruce Cran
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Fri Jan 28 08:21:37 UTC 2011 
State-Changed-Why:  
This is really old and wont probably be resolved. Please get back to me 
in case you feel this is wrong. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20633 
>Unformatted:
