On Wed, 22 Mar 2017 17:26:38 +0100 Michele Bucca <michele.bu...@gmail.com> wrote:
> Not all BIOSES support GPT. My old PC (2007) is still using a BIOS and does > not support GPT I guess AFAIK, it does not really matter if a BIOS recognizes a GPT - well, unless you want to be able select a specific *partition* within the BIOS boot options and AFAIK many/most BIOSes don't even support boot selection for anything other than at the *drive* (MBR) level anyway. The idea is that the boot loader, installed in the MBR at the start of the boot disk (and even GPT disks still have an MBR where a boot loader can be placed), is what actually selects which partition (or should I say other sectors) to boot (load). So, as long as the boot loader can do it's job, it really does not matter if the BIOS knows what the heck a GPT is. Furthermore, surprisingly enough, even the boot loader itself does not have to understand GPT. For example, the venerable LILO boot loader can work with with GPT disks because all it does is load in the requested sector numbers for the second stage boot loader and then does the same for the specific kernel image to load. As long as the BIOS can retrieve the requested boot sectors from the bootloader by absolute sector numbers alone, the boot system should work. And LILO et al. will "understand" what and where the partitions are as long as the kernel does as in /dev/sXY when LILO et al. is run to install the loader. i.e., GPT aware kernel = GPT compatible LILO, at least when LILO is booted from an MBR (even the one within a GPT disk). Other than RAID setup problems, the main limitation with older boot loaders such as LILO is that using 32bit sector numbers means that it can only "reach" the first 2TB of drives using 512 bytes/sector. That issue can be overcome, at least for Linux only systems, by ensuring that /boot is a partition of it's own located within the first 2TB. (Again, once we can get a kernel image into memory, we're pretty much good to go as far as the boot process goes.) Also, I don't know if LILO or the other older boot loaders can handle modern 4096 byte / sector drives - and then there is the 512 byte/sector "emulation" angle on such modern drives. Anyway, there seem to be only two potential problems with older BIOSes with GPT disks, and they are both uncommon: http://www.rodsbooks.com/gdisk/bios.html One is that certain BIOSes want to see a bootable partition which won't exist on standard GPT disks. This problem can be overcome simply by setting the bootable flag on the protective MBR partition of the GPT disk (via the experts' menu of gdisk). Some uncommon older motherboards (e.g., Biostar PT880 Pro-A7, circa 2006) require "believable" ancient C/H/S (cylinders, heads, sectors per track) drive geometry info even though the system/drive is using the modern sane LBA (sector number) addressing. Again, this can be overcome by setting the protective MBR on a GPT disk to have the needed fake (and meaningless anyway on drives made in the last 20-30 years) CHS values (again via the experts' menu of gdisk). In short, the uncommon BIOS problems with GPT can be overcome by setting appropriate "lies" in the protective MBR using gdisk. While on the subject, anyone else out there also think that UEFI is overly complicated BS? - all they ever needed to do was extend the old MBR system to overcome the partition number, sector addressing, and first stage MBR boot loader size and number limitations: http://yarchive.net/comp/linux/efi.html "From: Linus Torvalds EFI is this other Intel brain-damage (the first one being ACPI). It's totally different from a normal BIOS, and was brought on by ia64, which never had a BIOS, of course. Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now have x86 machines with EFI as the native boot protocol." UEFI still does not overcome the need have to load any special drivers required to access add-on card boot devices (as if that were even possible - we can't expect a system to be able to use hardware it hasn't been taught to understand), and once a kernel can be loaded into memory with all needed drivers, we're home free anyway. Booting just boils down to just being able to select arbitrary blocks of data (kernel images, each still only about 20MB of typical size today) to load into memory and then execute. Wouldn't have been better to have, say, a standard SDcard slot - a "universal memory boot device (UMBD)" - on the motherboard which can contain "files" of OS (kernel) images or boot loaders. The images could be "addressed" by sector numbers alone, like memory and not even need or use any specific filesystem. (IIRC, Grub does something like this with its special EF02 "BIOS boot partition".) The BIOS could then select which SDcard image to load into memory and execute it. One could also use one "OS image" for a more sophisticated custom boot loader and then get any boot prompt, custom logo, etc. from that point on. (Of course, we can obtain something like this today via those neat little $5-$10 SDcard to SATA/IDE adapters.) And so the BIOS would not have to deal with the changing world SCSI/SATA/IDE, etc. drivers at all - just push all that totally to the kernel/OS level. Incidentally, it's easy to test GPT or other boots, and make emergency boot "disks" with these little SDcard/SATA adapters. A "secure boot" feature could be implemented in such a system whereby a "secure/protected" OS boot image could be set to not be alterable after (BIOS) boot time (e.g., by the OS or installation software, except possibly with a signed image and even that option could be inhibited via BIOS settings.) However, within the BIOS setup screen, a user could always manually delete any such image. Furthermore, any bad/corrupt/lockedout/malwared SDcard/UMBD could always be physically removed and replaced. And another related rant - the write protect switch on SD cards should be enforced at the hardware level and not in the bogus way they actually do serving only as overrideable software flags "suggestions" to the OS driver. Booooo! to whoever is responsible for that design choice. Just my $0.02. Cheers, Mike Shell -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style