Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!sgiblab!swrinde!cs.utexas.edu!howland.reston.ans.net!sol.ctr.columbia.edu!destroyer!nntp.cs.ubc.ca!news.UVic.CA!softwords!cue.bc.ca!jnemeth
From: jnemeth@cue.bc.ca (John Nemeth)
Subject: Re: fdisk
Message-ID: <1994Feb16.082557.9631@softwords.bc.ca>
Sender: news@softwords.bc.ca (CNews)
Nntp-Posting-Host: cue.bc.ca
Organization: Computer Using Educators of B.C., Canada
References: <0hI0M_u00WB7EC5GkR@andrew.cmu.edu> <jmonroyCKupzM.4sz@netcom.com> <2j77im$a0h@u.cc.utah.edu>
Date: Wed, 16 Feb 94 08:25:57 GMT
Lines: 187
In article <2j77im$a0h@u.cc.utah.edu> terry@cs.weber.edu (Terry Lambert) writes:
>The second thing I left out was a definition of "The Right Way". If
>you have followed either the FreeBSD-hackers mailing list, or these
>news groups (actually, I believe I had an almost 100% solution to
>the problem as far back as comp.unix.bsd -- and posted it there),
>you will know what I think should be done; however, for the edification
>of the few who have not yet seen the list, I repeat it here.
I've been following this problem since the days of comp.unix.bsd
as well and was wondering when somebody was going to come up with the
right answer. I must have missed this the first time around. It is
very good, but I do have a couple of comments.
>The following is an almost verbatim (I have made some corrections) repeat
>of a previous posting on this matter:
>==BEGIN INCLUDED TEXT======================================================
>= 1) There should always be a DOS-style Master Boot Record on Intel
>= based BSD hard drives. This reduces the "does it or doesn't it"
Definitely. This is a must.
>= installed later without causing problems. I personally nominate
>= the OS-BS program for this, since it supports booting from second
>= drives and does not have GPL restrictions.
There are a number of boot selectors. I don't care which one is
used as long as it works (and preferably doesn't have GPL restrictions).
>= 2) The boot blocks need to be modified to pass additional information
>= in to the kernel. This information will be used during install,
Yes, the kernal should always be using the BIOS specified
geometry. This would require changes to the WD driver to not reset
the disk subsystem or to re-initialise it (Set Drive Params, code
0x91) with the BIOS values
>= something that should NOT be mandatory). The inode
>= number alone is sufficient to locate the kernel if the
>= kernel is limited to a location on "/", the name is
>= needed if the boot code is changed to be able to locate
>= a kernel by path in a subdirectory of a UFS FS.
Every other UNIX system that I have administrated (a lot) has
this feature, so I think it is something to put on the todo list.
>= Known "gotcha"'s:
>=
>= 1) For disks that aren't recognized by BIOS (such as would occur with
>= a Adaptech SCSI controller with BIOS disabled in a machine where
Adaptec controllers use a fixed geometry that have either 1 MB or
8 MB per cylinder, so it should be possible to figure out the geometry
without relying on the BIOS.
WD1003 based drives are a much bigger problem. Yes, I realise
that IDE (actually ATA) is a superset of WD1007 which is a superset of
WD1003, but that is irrelevant to this problem. I've been servicing
PC's for the last several years (trying to get out of that rut) and
have often had to determine the BIOS geometry of a drive in order to
transfer it to another machine or to reset the CMOS memory on a
machine (PC's are the only machines that I know which love to lose the
contents of their NVRAM). One solution that I have used successfully
is to read the MBR and analyse the partition table. I look at all
valid partitions and pick out the highest cylinder plus two, the
highest head number plus one, and the highest sector number that I see
and use those values as the geometry of the drive. Note, that there
is often a cylinder reserved for diaganostics, hence the reason for
adding two to the highest cylinder number. This method has never
failed. I have written a program to do this for me, but I am in the
process of rewriting it, so I don't want to post it at this time.
Another possible solution would be to store the geometry on the
drive somewhere. Since the drive is non-bootable, all of the MBR,
except for the partition table, should be fair game. I could easily
throw together a program to do this for WD1003 compatible drives, but
I don't know enough about ASPI or Adaptec controllers yet (it's on my
list) to do it for SCSI drives.
>= b) The disks on the secondary controller can not be used to
>= boot BSD; since the BSD boot blocks are BIOS based, and
>= the BIOS has no knowledge of the controller, devices on
>= a controller without BIOS recognition can not be used as
>= boot devices.
True, but given my above solutions, they could be shared with
MS-DOS.
>= 2) Not all translation is linear in the BIOS; if the controller is one
>= which supports bad sector forwarding in BIOS instead of in hardware,
>= the bad sector forwarding will be disabled. Worse, there will be
>= a possibility that the layout policy is such that BSD tromps on
>= the bad sectors forwarded by the BIOS, or vice versa. This type
>= of sector forwarding should be disabled, if at all possible.
This is a problem and I agree that bad sector forwarding should
not be done by the BIOS. If an OS wants to do bad sector forwarding
within its own partition then that's fine.
>= 4) The bad sector forwarding algorithm in BSD itself locates the bad
>= sector replacement table at the end of the drive instead of the
>= beginning; this means that the BIOS boot blocks may be able to
>= reference forwarded bad sectors from locations written to in
>= writing the UNIX kernel during linking and/or copying to "/".
>= This can result in some block in the kernel existing beyond the
>= DOS 1023 cylinder boundry, rendering it unbootable with the
>= BIOS boot blocks. The entire BSD disk layout policy needs to
Your message got truncated, but I think I can figure it out. I
agree that there are some major problems with the way that BSD handles
hard drives.
>==END INCLUDED TEXT========================================================
>
>The following is a subsequent posting to a question about drives only
>indirectly supported by BIOS from DOS -- that is, that don't have a
>DOS driver to ask geometry from until after DOS has been booted:
See my above solutions. We need to either analyse the drive and
determine the geomtry or store the geometry on the drive so that it
can be retrieved when the drive is attached.
>In closing, I would also like to note several things which may not have
>occured to the majority of the people who might be tempted to go out
>and implement all this:
>
>1) There are already good people working on this; you could mail
> them at freebsd-hackers@freefall.cdrom.com and ask them if
> they could use your assistance instead of trying to reinvent
> the world.
I seem to remember a posting from Amancio Hasty saying that he
was going to work on it. I plan on running NetBSD and this problem is
one of the ones that I want to work on, so when I get my system up and
running, I'll try to find anybody else working on this problem. In
the meantime, I would be willing to help where I can (I do have the
source code for NetBSD 0.9-current, but don't have it running yet).
>2) The DOS FS should be updated with concommitant changes at the
> same time if this is done; there is no reason to reserve any
> partitions for DOS when the DOS FS could, under this system,
> simply read and *correctly interpret* the DOS partition table
> off the raw whole disk without a need for a mount specific
> driver dev node.
I was thinking of using the System V method of handling the DOS
type partitions (i.e. in SCO UNIX, /dev/0s0 is all of the first
physical drive starting with the MBR, 0s1 is the first partition, ...,
0s4 is the last partition). This would solve the PCFS/DOSFS problem
quite nicely (i.e. 'mount -t pcfs /dev/0s1 /DOS'). I haven't decided
on a nameing convention, but that is minor compared to the rest of the
problems.
>3) All boot blocks written for use in DOS style partitions need
> to checksum to the correct value. This is why most operating
> systems besides DOS, OS/2, and SCO can't be booted using the
> OS/2 boot manager.
As far as I know, there is no checksum, just a flag word (0xAA55)
at the end of the boot block to indicate that it is valid.
Considering that the boot block needs to be written in assembly
language anyways, this shouldn't be much of a problem. The flag word
could also be stuck there by disklabel whenever it puts new boot
blocks on a disk.
>4) The changes to do partition handling really, really want to be
> made in the kernel low level block I/O code for use by all of
> the filesystem types on a given box; further, they want to
> be isolated to a single code layer so that Amiga, MAC, SPARC,
> PPC, and Alpha versions of the FS code *don't* require a DOS
> partition table to be able to run.
Yes. One of the reasons that I plan on running NetBSD is that
they appear to be doing the right things (including getting all the
machine specific stuff out of places it doesn't belong; thereby,
makeing it more portable, which is one of the biggest features of
UNIX).
>Feel free to post corrections as you feel necessary; I'll consider them
>on their merits and respond.
If you respond to this posting, please email me as well, since my
news server (which isn't under my control) takes a week to process
postings.
--
John Nemeth jnemeth@cue.bc.ca
System Administrator
Computer Using Educators of B.C. Opinions are my own.