I suspect you're getting hung up on the fact that separate partitions are required for the GRUB/GPT and EFI approaches, but that's not a big deal. The EFI approach is the safest and most flexible approach. The BIOS/MBR approach is the least safe and the most clumsy of the three approaches I've just outlined. This is subjective, of course, but I disagree with that assessment. GhostMotleyX, your comment to LiveWireBT's response opined that the "best" way to install is BIOS/MBR. EFI's newness also means it's not as well-tested, which accounts for a host of EFI-specific problems.) (OTOH, EFI also stores data on boot loaders in NVRAM, which creates a second point of failure in the boot process. This makes them easier to identify and manipulate. The EFI approach is much safer and much more flexible than the BIOS approach, since it doesn't tuck raw code away in weird places boot loaders reside in files, just like OS-level programs. GParted and parted identify the ESP as having its " boot flag" set, although that terminology means something completely different on MBR disks.) An ESP can exist on either a GPT disk or an MBR disk, but the former is much more common on EFI-based computers. ( Confusingly, Debian and Ubuntu installers refer to the ESP by the name "EFI boot partition," but this name is non-standard. On a computer with a newer EFI rather than a BIOS, boot loaders are not stored in the MBR, in officially-unallocated post-MBR sectors, or in BIOS Boot Partitions instead, boot loaders reside as ordinary files on a FAT partition known as the EFI System Partition (ESP).This is actually safer and cleaner than the MBR approach, since it serves to protect the GRUB code from other programs that might try to use that unallocated space. GPT offers no analogous place for GRUB to hijack, so GRUB's developers settled on the BIOS Boot Partition (which GParted and parted identify by a bios_grub flag) to hold the code that would go in the post-MBR sectors on an MBR disk. On a traditional BIOS-based computer with a new GUID Partition Table (GPT), the GRUB code is similar to that in the preceding case however, the sectors immediately following the MBR are not unallocated they're used by the GPT itself.This is a real mess, and it works only because developers have had literally decades to create clever hacks and work out (almost) all the kinks. Some of it's in the boot-code section of the MBR, some of it's in post-MBR sectors that are officially unallocated, and some of it's in the Linux /boot partition. On a traditional BIOS-based computer with a traditional MBR partition table, GRUB's executable code gets spread around like spaghetti thrown by a baby.GPT), but two of them have identical needs (and one of those is exceedingly rare):
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |