From owner-freebsd-hackers Fri Jan 27 18:59:58 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA04235 for hackers-outgoing; Fri, 27 Jan 1995 18:59:58 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA04228; Fri, 27 Jan 1995 18:59:40 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA18071; Sat, 28 Jan 1995 13:56:35 +1100 Date: Sat, 28 Jan 1995 13:56:35 +1100 From: Bruce Evans Message-Id: <199501280256.NAA18071@godzilla.zeta.org.au> To: jkh@FreeBSD.org, terry@cs.weber.edu Subject: Re: >1024 cyl IDE drive Cc: hackers@FreeBSD.org, hoppy@appsmiths.com Sender: hackers-owner@FreeBSD.org Precedence: bulk >> 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 ; 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 ; Thu, 24 Nov 1994 18:31:28 -0500 Received: by spiff.gnu.ai.mit.edu (5.65/4.0) id ; 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'. 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