Date: Wed, 23 Dec 2009 08:43:19 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= <des@des.no>, "James R. Van Artsdalen" <james-freebsd-current@jrv.org> Subject: Re: Some notes on RootOnZFS article in wiki Message-ID: <200912230843.19995.jhb@freebsd.org> In-Reply-To: <86my1b5c9s.fsf@ds4.des.no> References: <200912210600.46044.mel.flynn%2Bfbsd.current@mailing.thruhere.net> <4B30CCB3.1090401@jrv.org> <86my1b5c9s.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 22 December 2009 9:11:43 am Dag-Erling Sm=C3=B8rgrav wrote: > "James R. Van Artsdalen" <james-freebsd-current@jrv.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912230843.19995.jhb>