Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Jan 1995 13:56:35 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        jkh@FreeBSD.org, terry@cs.weber.edu
Cc:        hackers@FreeBSD.org, hoppy@appsmiths.com
Subject:   Re: >1024 cyl IDE drive
Message-ID:  <199501280256.NAA18071@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> I told you so.  Being right about it doesn't make it suck less.  8-(.

>Actually, you weren't even the first to tell me so.  A guy on USENET
>was the first to post this REALLY LONG article about it! :-)

Someone told us long before that in the enclosed mail to freebsd-bugs.
I thought it was well known to boot block hackers.

Bruce

>From owner-freebsd-bugs@freefall.cdrom.com Fri Nov 25 10:35:15 1994
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id PAA14743 for bugs-outgoing; Thu, 24 Nov 1994 15:31:31 -0800
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id PAA14737 for <bugs@FreeBSD.org>; Thu, 24 Nov 1994 15:31:29 -0800
From: room42@gnu.ai.mit.edu
Received: from spiff.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (8.6.9/4.0) with SMTP
	id <SAA07127@albert.gnu.ai.mit.edu>; Thu, 24 Nov 1994 18:31:28 -0500
Received: by spiff.gnu.ai.mit.edu (5.65/4.0)
	id <AA08604@spiff.gnu.ai.mit.edu>; Thu, 24 Nov 94 18:30:37 -0500
Message-Id: <9411242330.AA08604@spiff.gnu.ai.mit.edu>
Subject: URGENT - Install 2.0 trashes DOS partitions?
To: bugs@freebsd.org
Date: Thu, 24 Nov 1994 18:30:35 -0500 (EST)
X-Mailer: ELM [version 2.4 PL5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 7140      
Sender: bugs-owner@freebsd.org
Precedence: bulk
Status: RO


This URGENT bug report describes a possible disk partitioning problem
that might potentially trash large numbers of users hard disks. Please
ensure it is examined BEFORE CD-ROMs are mastered. It may well be a
false alarm but I think somebody who knows more about this than I
do better take a look.

The problem is that disk geometry remapping is not only performed
by the IDE controller or BIOS but also on many machines by special 
boot programs in the MBR sector which might appear to be the same 
as a BIOS remapping to FreeBSD utilities, but unlike a BIOS
remapping would disappear when the MBR is re-written unless special 
precautions, not mentioned in the INSTALL file, are taken.

Although there are many such machines around, they are unlikely to
have been used in FreeBSD testing as explained below.
 
According to the INSTALL file.

vvvvvvvvvvvvvvvvvv

At this point we're happy with the slices on the first drive, so we type
`w' to write the new information out.  It also prompts to make *sure* we
really want to do this, so we backspace over the default of `N' and type
`y'<return>.  And this point, we also can decide whether or not we want a
"boot manager" installed.  A boot manager is a little utility that prompts
you for the operating system you want to boot every time you reset or power
on your PC, and can be a very handy way of sharing your computer between
FreeBSD and some other OS, like Linux or DOS.  We decide that we want to
have this feature, so we `b' to write the special MBR (B)ootcode out to the
disk.  This does not harm any of the other operating systems on the disk,
as it's written to a special area.  Now we exit this screen by typing `q',
for (Q)uit.

^^^^^^^^^^^^^^^^^^

I believe this MAY "harm any of the other operating systems on the
disk" under circumstances that could be quite common but have escaped
FreeBSD release testing. That could result in the sort of reputation
that was achieved by early forms of disk compression!

There is no reference here to MBRs that perform geometry remapping. That
is either a minor and fairly harmless flaw in the documentation or a
MAJOR disaster that could result in significant numbers of hard disks
being trashed. FreeBSD is now easy enough to install that many people
will be able to do so who do NOT have the sense (or the tape drive) to
do a full backup first and who have no idea what an FDISK partition
or MBR is or does.

I have not studied the code, or even installed the software yet, let
alone experienced any problem, so this may be a completely false alarm,
however the potential implications are serious enough to be worth the
risk of wasting your time (and mine) on checking this out - especially
as CD-ROMs that will reach a much wider audience are presumably being
mastered right now.

Many clone PCs are now being sold with disk drives that have more
than 1024 cylinders but no geometry remapping support in the IDE
controller or BIOS. A disk utility is used by the clone supplier,
(before delivering the machine to the user, so most users would be
unaware of its significance), which installs its own boot code in the
MBR. (It signs on before the "Starting MSDOS" message and there is
no driver in CONFIG.SYS or AUTOEXEC.BAT). Presumably this does
geometry remapping in the same way that a BIOS would.

This is a common approach for clones with over 500MB drives, which
would be popular for many potential FreeBSD users (but have only 
recently become common).

There is a clear warning in the accompanying documentation that
this will not work with Unix partitions and that a "startup" floppy
which can restore the MBR should be made in case the DOS partitions
appear to have disappeared one day. (But only obsessive-compulsive
paranoids read such documentation :-).

If FreeBSD writes out a "standard" boot sector then presumably
this code would be lost, unlike the "normal" BIOS remapping which
you have presumably provided for. At best that would merely require
restoration from a backup of the original MBR, as provided for
in OS-BS. If that backup has been ENFORCED by the install procedures
then this may be only a minor documentation flaw in not explaining
(likewise if some other solution has been provided or if for some
reason there is no problem - the documentation should simply be
improved when convenient for the benefit of paranoids who read 
their disk controller manuals and/or who insist on having their
installation floppies write protected and only made an 
unprotected copy of the wrong one :-)

At worst however it might be that a user finds DOS booting up with
a partition that can read enough of the first few sectors (before
the different geometries matter) to pick up an apparently valid
FAT table, and proceeds to totally scramble their disk while making
copies of new CONFIG.SYS and AUTOEXEC.BAT files to figure out why
things no longer seem to be working.

An intermediate possibility is that that any problem always results
in an unbootable hard disk rather than a scrambled one, but keeping
a backup MBR is left to the user's discretion, as in OS-BS, which 
isn't really viable with the improved installation procedures (and 
mass market CD-ROM distribution) allowing people who don't know what 
they are doing to try it out. (Cf the precautions NOW taken by
MSDOS disk compression with NO user discretion about them - AFTER
numerous disasters.)

I am concerned that a problem could easily have slipped by because:

a) Most (or perhaps all) FreeBSD testers that have DOS would 
never think of trying to install FreeBSD on a machine which ONLY
has a single DOS partition for the whole disk - which is the most
likely scenario for a user with one of these geometry remapping MBRs.
(Not needed and therefore not installed by the utility unless the
DOS partition uses over 1024 "real" cylinders AND there is no
BIOS remapping - i.e. usually a "whole disk"). Also I suspect that 
FIPS might successfully reduce the size of the partition to leave room
for a second one since it could see and use the remapped geometry
correctly as long as the special MBR is in place, just as though
it was in the IDE controller or BIOS.

b) The FreeBSD 1.1 installation only referred to BIOS remapping (and
did not provide an automated solution or mention that simply using
fdisk -i to correct the BIOS geometry AFTER making the disklabels 
and re-booting from floppy eliminates any need for hand-crafting 
to deal with BIOS remapping). There was no reference to MBR remapping, 
so you might well be unaware of it.

Anyway I'm sorry if this wastes your time (which incidentally is
GREATLY appreciated - THANKS for FreeBSD!). But I simply CAN'T
check it out myself immediately and I thought it would be
irresponsible to delay reporting the possible problem until I
can be sure I am not just exposing my (considerable) ignorance.
So I am just doing what I can TODAY to draw your attention to the 
POSSIBILITY.

Seeya,

Albert

PS. If these are mailing lists sorry, but I haven't even
subscribed (before panicking :-). Please CC any response direct.

-- 
Albert.Langer@gnu.ai.mit.edu
Disclaimer: "I am not a Marxist" - Karl Marx




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501280256.NAA18071>