From owner-freebsd-bugs Sat Aug 17 11: 0:17 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D7937B400 for ; Sat, 17 Aug 2002 11:00:09 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC8243E42 for ; Sat, 17 Aug 2002 11:00:08 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7HI08JU037104 for ; Sat, 17 Aug 2002 11:00:08 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7HI08Di037103; Sat, 17 Aug 2002 11:00:08 -0700 (PDT) Date: Sat, 17 Aug 2002 11:00:08 -0700 (PDT) Message-Id: <200208171800.g7HI08Di037103@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Artem 'Zazoobr' Ignatjev" Subject: Re: bin/20633: fdisk doesn't handle LBA correctly Reply-To: "Artem 'Zazoobr' Ignatjev" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR bin/20633; it has been noted by GNATS. From: "Artem 'Zazoobr' Ignatjev" To: Bruce Evans , 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message