Date: Tue, 26 Nov 1996 17:54:26 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, p.richards@elsevier.co.uk Cc: current@freebsd.org, fenner@parc.xerox.com Subject: Re: 2.2-ALPHA install failure Message-ID: <199611260654.RAA29950@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>A colleague here that I just co-erced into switching from SCO to >FreeBSD (Ok, didn't take that much effort) has had some problem that >I'm still collecting info on but basically, it seems that he had set >the number of cylinders in his BIOS to some large value and that SCO >had written a MBR that had used the full number of bits from the BIOS >for the number of cylinders (i.e. without truncation) and from our >initial guess and put FF's into the other MBR entries. It's impossible to write the number of cylinders without truncation. There are only 10 cylinder bits to write to. >FreeBSD isn't seeing the partitions on the the end of the disk because >our bootblock masks the high bits of the no. cylinder field from the >BIOS (perfectly correctly as per spec) so FreeBSD has a weird idea of >things since SCO wrote the MBR and cheats by using the all the bits >the BIOS sends provides it. FreeBSD or the FreeBSD boot block or the MBR? FreeBSD ignores the C/H/S values except to guess the geometry and the geometry is only used by utilities (sysinstall and fdisk). It uses the linear sector numbers for almost everything. The geometry-guessing part knows something about both truncated values and FF's in all the C/H/S values (it skips the entries with all FF's since they provide no useful information). The FreeBSD boot block ignores the C/H/S values completely. It uses only the linear sector numbers (the offset at least) and the BIOS geometry (obtained simply by asking the BIOS). Most MBR's use only the starting C/H/S value for the partition to be booted. >> Flexible SCSI BIOS geometries also cause interesting bootstrapping >> problems. Suppose that the geometry is initially 64/32 for some reason, >> ... >Hmm, can't the driver contain this knowledge? i.e. the driver could >export it's default geometry to userland so libdisk knows what the >default geometry for that controller is and use it in preference to >guessing. No. It would only work for the simple case of a new disk. If there is already a partition table on the disk, then the driver must not pick an arbitrary default. Then there are complications determining what the controller actually supports. E.g., you would have to read the "DOS > 1GB" switch on Buslogic controllers. >DOS never seems to have these problems and when I run into >difficulties I usuall stick a small DOS partition on the disk to get a >valid MBR. I assume it's just letting the controller pick a default. That's partly because it doesn't support cylinders >= 1024. If the controller picks a default with >= 1024, you lose. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611260654.RAA29950>