From owner-freebsd-current Sat Nov 23 13:24:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14022 for current-outgoing; Sat, 23 Nov 1996 13:24:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA14016 for ; Sat, 23 Nov 1996 13:24:06 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id IAA05102; Sun, 24 Nov 1996 08:19:46 +1100 Date: Sun, 24 Nov 1996 08:19:46 +1100 From: Bruce Evans Message-Id: <199611232119.IAA05102@godzilla.zeta.org.au> To: current@freebsd.org, fenner@parc.xerox.com Subject: Re: 2.2-ALPHA install failure Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I forgot that the partition table was probably wrong, too. I ran fdisk >from the fixit floppy, and sure enough, it said 2 million tracks, 1 >head, 1 sector per track. These numbers come from the same place as in sysinstall: from dsinit() reading the partition table and misinterpreting the garbage in it. diskslcie_machdep.c has a lot of code to check the partition table, but the return codes are always ignored :-( and the error messages are not printed unless the kernel is booted with -v :-(. >So I tried to edit it, and experienced some >awfully confusing fdisk behavior. I entered 109 sector/track, 4 heads, >4839 cylinders. I said "no" to manually setting the start/end of the >partition, and it made the start 0/1/0 and the end something like >735/36/0. Seems to me that since the partition is the whole disk, the >end should be at least 1023/... This behaviour is very natural if you know that there are only 6 sector bits, 8 head bits and 10 cylinder bits. Values larger than 1023/255/63 get truncated mod 1024/256/64 in each field. Geometries which would cause truncated sector or head bits must not be used. Truncation of cylinder bits is usually harmless provided you don't want to boot from a partition above cylinder 1023 or run a lesser O/S that doesn't support such partitions. >In any case, after writing the partition table twice (the first time, >for some reason, when I re-checked it it was back to 1/1.), I was able >to boot my new drive (yay!). However, fdisk now says: 109 sector/track gives a different type of garbage that happens to work (perhaps by making it obvious to the ncr BIOS that the partition entry is garbage so it defaults to something that works (in the dedicated case only)). Flexible SCSI BIOS geometries also cause interesting bootstrapping problems. Suppose that the geometry is initially 64/32 for some reason, but you don't want that. You run fdisk and tell it the geometry that you want (normally 255/63) and then change the partition table, being careful to end partitions on (new) cylinder boundaries. The kernel will detect the changed geometry in some circumstances. The SCSI BIOS will detect on the next boot. However, if you make a mistake with the cylinder boundaries, then the SCSI BIOS might detect garbage and switch to a default that might not work. It's safest to reboot immediately and check that the changes worked right. Bruce