Bug 20633

Summary:	fdisk(8) doesn't handle LBA correctly
Product:	Base System	Reporter:	sjr <sjr>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.1-STABLE
Hardware:	Any
OS:	Any

Description sjr 2000-08-16 05:00:01 UTC

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.

Comment 1 jhb 2000-08-25 10:05:42 UTC

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/

Comment 2 Sheldon Hearn freebsd_committer

2000-08-25 10:16:21 UTC

Responsible Changed
From-To: freebsd-bugs->jhb

Let's see if we can pin this on John without getting 
our hands slapped. :-)

Comment 3 John Baldwin freebsd_committer

2001-03-11 01:44:12 UTC

State Changed
From-To: open->closed

The described behavior is not a bug but just a quirk of the PC BIOS.

Comment 4 John Baldwin freebsd_committer

2001-03-16 19:14:36 UTC

State Changed
From-To: closed->open

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

Comment 5 John Baldwin freebsd_committer

2001-03-16 19:14:36 UTC

Class Changed
From-To: sw-bug->change-request

This is now more of a feature change request than an actual bug.

Comment 6 John Baldwin freebsd_committer

2001-03-16 19:14:36 UTC

Responsible Changed
From-To: jhb->bugs

Kicking this back over to bugs as I don't have time for fdisk right now.

Comment 7 bill fumerola freebsd_committer

2001-03-17 06:45:57 UTC

Responsible Changed
From-To: bugs->freebsd-bugs

correct mailing list

Comment 8 Artem 'Zazoobr' Ignatjev 2002-08-16 13:56:01 UTC

	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.

Comment 9 Artem 'Zazoobr' Ignatjev 2002-08-16 19:42:35 UTC

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.

Comment 10 Bruce Evans 2002-08-17 17:12:45 UTC

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

Comment 11 Artem 'Zazoobr' Ignatjev 2002-08-17 18:56:24 UTC

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.

Comment 12 Bruce Evans 2002-08-17 22:45:23 UTC

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

Comment 13 Rebecca Cran freebsd_committer

2010-09-12 11:50:34 UTC

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

Comment 14 Remko Lodder freebsd_committer

2011-01-28 08:21:37 UTC

State Changed
From-To: open->closed

This is really old and wont probably be resolved. Please get back to me 
in case you feel this is wrong.