From owner-freebsd-questions@FreeBSD.ORG Sat Jan 24 01:42:23 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 473D116A4CE; Sat, 24 Jan 2004 01:42:23 -0800 (PST) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08DC643D1F; Sat, 24 Jan 2004 01:42:21 -0800 (PST) (envelope-from hhasenbe@techfak.uni-bielefeld.de) Received: from fwd02.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1AkKIy-0006T5-01; Sat, 24 Jan 2004 10:42:16 +0100 Received: from techfak.uni-bielefeld.de (SsEz8uZ1gevOnvpCZiPUXq93HWEYJu1E-bkJqNpu4lvq8ocUy3dUcO@[217.225.30.69]) by fmrl02.sul.t-online.com with esmtp id 1AkKIp-1wpLNo0; Sat, 24 Jan 2004 10:42:07 +0100 Message-ID: <40123E35.1010003@techfak.uni-bielefeld.de> Date: Sat, 24 Jan 2004 10:43:17 +0100 From: Hendrik Hasenbein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de, en, en-us MIME-Version: 1.0 To: Keith Kelly References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Seen: false X-ID: SsEz8uZ1gevOnvpCZiPUXq93HWEYJu1E-bkJqNpu4lvq8ocUy3dUcO@t-dialin.net cc: freebsd-bugs@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD/FDisk geometry problems - SOLVED! X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 09:42:23 -0000 Keith Kelly wrote: > I've found a bug in FDisk which is responsible for all the problems I've > had trying to get FreeBSD installed. I also found a work-around, and > I'm happy to report I'm typing this message from Konquerer inside > FreeBSD 5.1-RELEASE right now. Gratulation. > Basically, the problem is that FreeBSD's FDisk and the motherboard BIOS > independently calculate a set of CHS values (Cylinders/Heads/Sectors) > based on the total sector count of the disk, but they do it in different > ways and thus end up with different values. Yes. That is because there are different ways to calculate that. > So, the problem is that FDisk makes *different* assumptions than my BIOS > does about what the sectors and heads values should be. That has always been the problem for CHS conversions. > I ran across > some information on a BIOS manufacturer's site which claimed that for > "LBA mode" SCSI drives (more accurately known as "LBA-Assist translation > mode"), that it is safe to assume that sectors should be 63 and heads > should be 255. Given that FreeBSD's roots and developer community seems > historically SCSI-centric, I can see how these assumptions would have > been picked up and used in FDisk and considered acceptable. But these > assumed values are clearly not correct for how CHS gets calculated by > many PC BIOSes for IDE drives. LBA is the only common mode known to all BIOS vendors, Harddrive manufactures and so on, because at least someone made up some assumptions and published them instead of developing their own CHS translation. SCSI was first to breach the BIOS CHS barrier on PCs and so they defined that method. If your BIOS is in auto mode, it tries to get the current format from the harddisk most times uses CHS, but will also find a disk with LBA. So in a modern system LBA would be the safe pick and not CHS. Most likely it picks it from disk (the partition table uses entries for cylinders, heads and sectors to describe the partitions), so the first fdisk sets the addressing the bios chooses. So to avoid conflicts and enhance the usabilty of your drive in different PCs and with different systems use LBA. > Furthermore, I believe that the reason FDisk rejects the manually > entered CHS of 19618/16/255 is because either (1) it tries to enforce > those bad assumptions about heads and sectors, or (2) it gets confused > by the rounding error. In other words, in the case of rounding error, > FDisk may be taking the manually-entered values, multiplying them > together, and seeing that it doesn't exactly match (or come close enough > to, in its humble but flawed opinion) the total sector count for the > drive. The way Fdisk's geometry validation ought to work is like this: > > - Divide the total sector count of the drive by (H*S), where H and S are > the user-supplied values. > - Round the result to the nearest whole number. > - Compare that result to the user-supplied value for cylinders. > - If the result matches, accept the user's input as good. The test will ensure that the user dont make typos, but it can't ensure that the C. H and S are arranged the same in both conversions. > In the meantime, the workaround for anyone experiencing this problem is > to go into their BIOS and set the hard drive to "User" mode, and > manually enter the same C/H/S settings that FDisk calculated for the > drive. Unfortunately, I think this means that if you have to > repartition and reformat the entire drive, since the BIOS will now be > addressing the drive using different C/H/S settings and will be unable > to read any partitions that were formatting using different C/H/S > addressing. So while there is a workaround, it is far from an ideal > user experience. Better solution, put the IDE drives to LBA and you'll see that you get the same CHS every time and on every system except MSDOS < 6.3. If you got a filesystem which doesnt bother about CHS and uses linear addressing you 'only' need a new partition table. After redoing the drive you can put the IDE back to Auto. Hendrik