"James R. Van Artsdalen" <james-freebsd-current_at_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 table. I can assure you that Windows does not put in a dummy partition table, and will not boot if the partition is not active. 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) > 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. I can't quite parse that. The R&R partition on my T60 is not hidden in any way. > 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. 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. DES -- Dag-Erling Smørgrav - des_at_des.noReceived on Tue Dec 22 2009 - 13:11:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:59 UTC