From owner-freebsd-current@FreeBSD.ORG Wed Dec 23 14:38:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E48106566C for ; Wed, 23 Dec 2009 14:38:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 332F48FC18 for ; Wed, 23 Dec 2009 14:38:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 95C4A46B03; Wed, 23 Dec 2009 09:38:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 463488A01B; Wed, 23 Dec 2009 09:38:33 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 23 Dec 2009 08:43:19 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200912210600.46044.mel.flynn+fbsd.current@mailing.thruhere.net> <4B30CCB3.1090401@jrv.org> <86my1b5c9s.fsf@ds4.des.no> In-Reply-To: <86my1b5c9s.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200912230843.19995.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 23 Dec 2009 09:38:33 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , "James R. Van Artsdalen" Subject: Re: Some notes on RootOnZFS article in wiki X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:38:35 -0000 On Tuesday 22 December 2009 9:11:43 am Dag-Erling Sm=C3=B8rgrav wrote: > "James R. Van Artsdalen" writes: > > It definitely breaks things *when booting* to depend in any way on a > > partition table since there may not be one. By the mid 90's nearly > > every OS was putting in at least dummy partition tables for the same > > reason GPT does - to lessen the risk of accidental clobbering of the > > disk - but that's just a convention. I'm sure there are still a few > > customized VAR-things out there that don't bother with a partition tabl= e. >=20 > I can assure you that Windows does not put in a dummy partition table, > and will not boot if the partition is not active. That is due to Windows' MBR bootcode, not the BIOS. > I can also assure you that the BIOS on my current laptop (ThinkPad T60) > *does* care about the partition table, because the BIOS boot menu has an > option to launch the rescue & recovery utility, which is located on a > DOS partition at the end of the disk (although the BIOS works fine if > the R&R partition is missing) >=20 > > A number of vendors have taken to putting "hidden" system partitions on > > the disk with various utilities that can be run via a hotkey press > > during POST. These schemes have to use MBR-like code from the BIOS ROM > > to boot their system partition and that pseudo-MBR must read and > > interpret the partition table to find the system partition. But during > > system boot itself the MBR sector is read and if the last word in that > > sector is 0xAA55 then the BIOS executes the MBR code blind as to what is > > on the disk. It's the MBR code that's read from the disk that scans the > > partition table, if there is one. >=20 > I can't quite parse that. >=20 > The R&R partition on my T60 is not hidden in any way. Umm, you just said you have a recovery partition on your T60 which is what = he=20 is talking about here! Geez. Presumably by "hidden" he means that it does= n't=20 show up as a volume under Windows or OS X, so for the vast majority of folk= s=20 it is hidden. > > There were attempts for a time to check for boot sector virii before > > booting but those were always so problematic that I never did that, and > > I don't the the other main BIOS teams did it either. >=20 > I've had machines that had a BIOS option to check if the boot sector had > been modified and warn the user before booting. It worked just fine. That is not what he is talking about. He is talking about trying to analyz= e=20 the boot sector for known signatures, etc., not the simple write-protection= =20 scheme. Now, there are some examples I know of that involve BIOS's having too-intim= ate=20 knowledge of disk partitioning schemes. One is that the floppy emulation m= ode=20 in the "El Torito" CD booting code of certain IBM BIOSes assume that the=20 floppy disk is actually a DOS floppy disk complete with a BPB that the IBM= =20 BIOS writes to after it has been loaded. We have a dummy BPB in boot1.S as= a=20 workaround for that brain damage. Another instance is that some BIOS's=20 attempted to help with the C/H/S geometry disaster by examining the C/H/S a= nd=20 LBA addresses in the MBR to determine what C/H/S geometry the MBR was=20 expecting. They would then compute that C/H/S geometry and honor that for= =20 C/H/S to LBA conversions. It generally worked well. However, if you used = a=20 heads value of 256 in a C/H/S value in the MBR it would end up causing a=20 divide by zero that caused the boot to hang. The original fake MBR in boot= 1.S=20 for "dangerously dedicated" mode had a partition that tickled this particul= ar=20 bug and was changed to use 255 heads. There are more details on these in t= he=20 commit logs of boot1.S. Personally, most of my headaches dealing with BIOS's these days are dealing= =20 with SMM rather than disks. As an OS developer I loathe SMM. :) =2D-=20 John Baldwin