''EFI boot partition'' and ''biosgrub'' partition

Question

Why do I need these? I have installed Ubuntu under a non UEFI (master boot record) and have installed Ubuntu with no 'biosgrub' and it works fine, whereas other times I am asked to make a 'biosgrub' partition. I have no idea why sometimes I need it and others I don't (these have both been on the same system).

And the same thing happens when I use UEFI (GUID Partition Table). The only difference is I am asked to make a 'EFI boot partition', but as with the 'biosgrub', sometimes I am asked to make it and sometimes I am not asked to make it.

For my current install I was asked to make one but I didn't and my system is fine. There is no change in the system, same hardware, BIOS etc... Could anyone shed light on this?

Answer 1

There are four conditions (BIOS vs. EFI and MBR vs. GPT), but two of them have identical needs (and one of those is exceedingly rare):

• 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. 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. 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.
• 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. 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. 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.
• 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). (Confusingly, Debian and Ubuntu installers refer to the ESP by the name "EFI boot partition," but this name is non-standard. 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. 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. This makes them easier to identify and manipulate. (OTOH, EFI also stores data on boot loaders in NVRAM, which creates a second point of failure in the boot process. EFI's newness also means it's not as well-tested, which accounts for a host of EFI-specific problems.)

GhostMotleyX, your comment to LiveWireBT's response opined that the "best" way to install is BIOS/MBR. This is subjective, of course, but I disagree with that assessment. The BIOS/MBR approach is the least safe and the most clumsy of the three approaches I've just outlined. The EFI approach is the safest and most flexible approach. 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. Aside from when setting up the system or doing partition maintenance, those partitions will be pretty much invisible to you, and they give you a lot of flexibility. Unlike MBR, GPT is not limited to four primary partitions, so you needn't hoard your primary partitions like a leprechaun hoarding his gold.

Answer 2

You need to create a biosgrub partition on a GPT partitioned disk when setting up legacy booting or an EFI boot partition (for both GPT or MBR partitioned disk) when setting up UEFI booting.

• GRUB requires a BIOS Boot Partition (2 MiB, no filesystem, EF02 type code in gdisk or bios_grub flag in GNU Parted) in BIOS systems to embed its core.img file due to lack of post-MBR embed gap in GPT disks. [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}

Answer 3

I will give one extra point/motive for having both, EFI and BIOS grub.

USB stick to boot a Live SystemRescueCD.iso loop from Grub2.

Why? Simple answer: it will boot on a lot of PCs, some has UEFI some has only 32 bit old BIOS, etc.

Real complex motive: use advanced hardware (UEFI) if possible.

Real live use sample:

• USB stick (formated on GPT mode) with four partitions
• First partition (able to be seen from Windows 7 and up) on NTFS with the rest of the size of the USB stick
• Second partition for Grub2 and SystemRescueCD.iso file with at least 1GiB (better if 2GiB so you can carry two versions of SystemRescueCD.iso at same time, just for testing the new version prior to replace the old one), i normally use Ext4 filesystem for it
• Third partition for EFI (what windows call ESP) formatted as Fat32 with at least 512MiB (i have seen some PCs that if using less they do not show USB stick as a bootable media)
• Fourth partition for BIOS_Grub (no format, but cleared when created)

One important thing: I have seen a 8GiB LG USB stric (one i own) that refuses to be listed on an physical UEFI PC boot if partitions are not aligned to cylinders, but be seen on other UEFI PCs and also on VirtualBOX with UEFI boot mode activated... when partitioning it if aligned to MiB it does used all space, no near 1MiB unpartitioned space at end, but when aligned to cylinders the last incomplete MiB is not used... if i do MiB partitioning having that in mind (in other words i do a manual cylinder align) it works, but as i am saying it is still cylinder aligned (i am doing it manually instead of letting the partitioning tool to do it for you).

How to get such great USB recovery stick (it has two tricks):

1. Align partitions to Cylinders (better compatibility to just align to MiB)
2. Do a grub-install --target=i386-pc and then do another grub-install --target=x86_64-efi on the same grub partition, so you use only one grub.cfg for both boot modes

How it boots:

• a) booting form old BIOS, will load MBR, then Stage2 of grub form BIOS_grub partition, then core.img from Grub2 partition
• b) booting form UEFI compatible, will load .efi file from ESP partition
• grub.cfg is readed (if exists on grub2 partition)
• then grub2 menu is shown
• then i select to boot from loop SystemRescueCD.iso (with dochace parameter), i have set two options set on grub.cfg, one for 32Bits, one for 64Bits (i have really four options, since i set on two a dostartx parameter to boot directly on GUI).
• after boot i can eject the usb stick (the whole Live Linux is in ramdrive thanks to such docache), no need to type any command, pendrive is not mounted (again thanks to docache parameter).

With this stick i can boot old PC (if they let to boot from USB) in 32 bits or also 64 bits (if they have extension etend on procesor), but booting in BIOS mode.

With this stick i can also boot new PC (if they let to boot from USB) in 32 bits and 64 bits, but booting in UEFI mode (ah, yes it can boot in UEFI mode and then just boot Linux Live SystemRescueCD in 32 bit mode as well as in 64 bit mode).

So i have all in one usb stick recovery boot media, capable of booting in near all PCs, modern or old (only need USB boot support), no matter if 32bits or 64 bits, BIOS or UEFI, etc... and i can select what i want to run 32bits or 64bits.

Also more, i had tested on a PC that refuses to install Windows 64Bits (old 32Bits procesor), but be able to run a 64bit Linux Live (because PAE capability exists on that processor).

Side note: Such first partition as NTFS is for holding data that can be shared with Windows 7 and up (XP will not see it since does not support GPT partitioning)... it must be the first one, no need to be on initial part of the disc, can be wherever you want, but mush reside as first entry on partition table, this is caused by hateable windows mode to mount partitions on removable, it has code specificaly programmed to avoid accessing more than the first partition, so you can not mount the others at the same time.

Extra for Windows and USB partitions: If you swap partitions entries on partitiong table, in other words you put the partition you want to access as the first one in the table, windows will let you to access it (if its format is understand, fat32 and NTFS directly, ext2 with special drivers, etc), but will only let access to the one that is located on first entry of the partition table... there is a tool (called BootICEx86.exe) that can do such work on Windows without even need to unplug the usb stick.

Super extra: there is also some pendrives (i am very lucky to own one, a Sony 16GiB) than can be bit changed with special tools (mine with a tool from lexar) so they appear to Windows as an USB HDD instead a USB stick, after that change, all windows will let you delete, create and manage partitions on it, also more than one at same time can be mounted, each one with its own letter.

Linux users does not worry with that, since Linux see it as a partitionable block device and does not implement special code to block mounting partitions, etc, as windows has.

Oh, yes this last paragraphs are written just in case some one on M$ read them, so their face drop down to floor, i am trying (will not get it never, i know it is a lost objetive) to them to remove such ugly code from Windows and let users have partitions on usb stick in a native manner.