# grub2-install to GPT disk on BIOS machine?

## Havin_it

Hi,

I held off getting into GRUB2 until a *really* slow day, and now I know why. I've done it once, successfully, on a "normal" laptop but now I come to do it on my home server, trouble strikes. The machine is a HP Microserver N40L (I believe a certain Administrator knows his way round one of these  :Wink:  ) which is amd64, BIOS-based.

The problem is, when setting it up initially I put some 500GB disks in there and was advised to use GPT partitioning for some long-forgotten reason. The boot drive is a 250GB, also GPT (I like consistency!) and may well be some sort of hybrid nonsense with an MBR in there too; / and /boot are both on /dev/sda1 which is about 20GB.  The partition type is EF00 ("EFI System" according to gdisk) and filesystem ext4. Chainloading from grub-legacy, as suggested in the wiki, worked fine.

When I try to run grub2-install I get this error:

```
hazel ~ # grub2-install --modules="part_gpt fat ext2" --no-floppy /dev/sda

/usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.

/usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..

/usr/sbin/grub2-bios-setup: error: will not proceed with blocklists
```

Now I have read online that the above should work if the partition label is EF02 (BIOS Boot), and I see that I can use gdisk to change this, but should I? Also, should I do so while booted from and using that partition?

This won't be an issue until I need to reboot again so I'm not panicking, but I'd like to be sure I don't put my system into an unbootable state as the machine doesn't have an easily-accessible screen (have to drag my CRT telly the length of my home to hook it up). Any advice welcome!

----------

## NeddySeagoon

Havin_it,

A BIOS boot partition for EFI is vfat.  I suspect that all grub2 will tolerate.

It may get further if you change the partition type but I doubt that it will work.

You need to create a real vfat boot partition.

You may be able to force the use of block lists.  Its unreliable because you need to remember to recreate the block lists when their content changes.

Lilo has always worked this way, and yes its a pain when you forget.

Grub1 uses a blocklist to find stage2 in this setup, but not the kernel or initrd.

As I don't use grub2, and probably never will, I don't know what it uses blocklists for.

Its possible that grub2 will never be needed.  The kernel can be made an EFI compliant binary, so no bootloader is needed. An EFI BIOS can load it directly.

On legacy BIOS equipment, grub1 is adequate.

My HP Microserver runs a /no-multilib/ hardened profile, which makes the use of grub-static obligatory, since grub1 is a 32 bit binary, which cannot be run to install it.

----------

## whywhy

I believe you need a "Bios Boot Partition" (Type EF02) if you want grub2 to boot from a BIOS machine.

It has to be a separate partition by itself and there is no need to format any filesystem on it. It should not be used as part of your regular filesystems.

I have read that the minimum size can be as small as 31 KB, but setting larger is probably safer. Mine is 1 MB.

It should also be within the first 2 TB of the harddisk, in my case it is the first partition of the harddisk.

----------

## NeddySeagoon

whywhy,

I can understand why 31k would work. The the normal space before the first partition on a hard drive with a MSDOS partition table.

Grub1 and ither boot loaders use this space for their second stage, after the 440b of MBR code.

With a GPT disk label, this unused space is not present. The MBR at LBA 0 is still present, with the 'protective' MSDOS partition table.

----------

## Havin_it

Thanks for the replies both  :Very Happy: 

@NeddySeagoon, You cut to the heart of the matter sir - why bother? Reading the hoops one seems to have to jump through for this, I certainly am losing what enthusiasm I had for the upgrade. I did recall reading that grub2 supported automatically booting a fallback kernel in the event of a panic, which would be handy at times on this box, but there are probably other ways of doing that (kexec?).  I will admit to being a sucker for the "new shiny" (if a bootloader can truly be said to qualify) but it wouldn't be the first time that's brought me pain.

Prime example: got more bored last night and did it anyway (changed sda1 to EF02, grub2-install'd) and sure enough wound up unbootable. (I do actually have a sysresccd liveusb in my arsenal for when this happens, but I sure would have rather been sleeping than p**sing about in a chroot replacing grub1.)

Also the way things are going at the moment, part of me wouldn't rule out Lennart Poettering finding some reason to mandate grub2...!

@whywhy, I think you've just reminded me why I went GPT in the first place: I think I got the idea that if I upgraded to >2TB disks in future I'd need to use GPT. Not even sure if I had this right given what you say.

It might or might not be feasible for me to add an EF02 partition. sda1 is pretty crammed but I could spare a couple of MB I expect. However, (a) doing this would be a right pain sans GUI and (b) I have baroque worries about what sda2 becoming sda3 would do as it's part of a mdraid set.

Maybe best left for an even slower day!

----------

## NeddySeagoon

Havin_it,

If you feed mdadm the raide set UUIDs for --assemble, you can move things around as much as you want, the UUIDs will be found.

If you use SCSI device names, its more fragile.

GPT Partation tables support partitioning huge volumes, MSDOS can describe at most 2Tb (binary) of space.

----------

## srs5694

 *Havin_it wrote:*   

> The problem is, when setting it up initially I put some 500GB disks in there and was advised to use GPT partitioning for some long-forgotten reason. The boot drive is a 250GB, also GPT (I like consistency!) and may well be some sort of hybrid nonsense with an MBR in there too;

 

Hybrid MBRs are dangerous hacks, and I strongly recommend converting to a standard protective MBR unless you're sure you need a hybrid MBR. (They're mostly used on Macs that dual-boot Windows, but also on some Hackintosh setups.)

 *Quote:*   

> / and /boot are both on /dev/sda1 which is about 20GB.  The partition type is EF00 ("EFI System" according to gdisk) and filesystem ext4.

 

A gdisk type code of EF00 denotes an EFI System Partition, which is a partition type that's used only when booting a computer with EFI firmware. An ESP must normally be FAT32, and an ext4fs ESP makes no sense whatsoever. Chances are it's set up this way because you thought you needed a "boot flag" on the partition when using parted, since, parted's developers made the (IMHO poor) choice to use "boot flag" on GPT disks in a way that's completely unrelated to the meaning of "boot flag" on MBR disks, thus leading to this type of mistake.

You should set the type code of your Linux filesystem partitions to 8300 in gdisk. (Linux doesn't really care, but setting the right type code can help avoid problems with some tools or if you've got a dual-boot configuration. Also, I know of at least one firmware that does care about the type code and might flake out if a partition is marked as an ESP but can't be read.)

 *Quote:*   

> When I try to run grub2-install I get this error:
> 
> ```
> hazel ~ # grub2-install --modules="part_gpt fat ext2" --no-floppy /dev/sda
> 
> ...

 

IIRC, the "--force" option to grub2-install will force installation using blocklists, which is basically how GRUB Legacy does it on GPT disks. Alternatively, and more reliably, you can create a BIOS Boot Partition, as others have suggested. This partition can be small -- sometimes as small as 31KiB, although some configurations require 1MiB or even a little bit more, so 2MiB is the usual recommended size. The BIOS Boot Partition does not need to have a filesystem; in fact, GRUB just dumps code in "raw," so if you create a filesystem it will just get wiped out. (NeddySeagoon is confusing a BIOS Boot Partition and an ESP.)

 *Quote:*   

> I think I got the idea that if I upgraded to >2TB disks in future I'd need to use GPT. Not even sure if I had this right given what you say. 

 

This is correct (at least, mostly). The old MBR scheme uses 32-bit values to describe the start point and length of partitions. Given 512-byte sector sizes, a 32-bit value creates a 2TiB limit to both the start point and size of partitions. Thus, on an MBR disk, partitions cannot begin beyond the 2TiB point or be larger than 2TiB. In theory, you could use a disk of up to 4TiB by putting everything beyond (and starting before) 2TiB in a single partition, but that's the sort of arbitrary limit that can be very aggravating. Also, some OSes flake out when shown disks laid out like this. Thus, it's best to consider the 32-bit limit of MBR to be a limit on total disk size, and use GPT on over-2TiB disks.

----------

## NeddySeagoon

srs5694,

 *srs5694 wrote:*   

> (NeddySeagoon is confusing a BIOS Boot Partition and an ESP.) 

 

You are correct. Thank you.

----------

## Havin_it

 *NeddySeagoon wrote:*   

> Havin_it,
> 
> If you feed mdadm the raide set UUIDs for --assemble, you can move things around as much as you want, the UUIDs will be found.
> 
> If you use SCSI device names, its more fragile.

 

I don't actually feed it anything, assembly is full auto for me  :Very Happy: 

On the other hand, I notice gdisk has an option to "transpose partition numbers", which if I read it right would mean I could create a new partition before the current sda2, but then swap them so what would have just become sda3 could go back to being sda2, and the new partition became sda3, despite the on-disk order.  (Though whether the SCSI naming would follow what the GPT says is another matter, I guess!)

 *NeddySeagoon wrote:*   

> GPT Partation tables support partitioning huge volumes, MSDOS can describe at most 2Tb (binary) of space.

 

Looks like my surmise was correct about why on earth I used GPT in the first place then.  I think my thinking was that I might source larger disks piecemeal, and hopefully could add them dynamically to the RAID and then grow the partitions together once they were all bigger (though I've done no feasibility study whatsoever on whether this would actually work).

----------

## NeddySeagoon

Havin_it,

Growing raid sets is a two step process.  Making the underlying media bigger by replacing or adding drives, then using the new space.

You can use the new space by either changing the size of existing partitions, then growing the filesystem.  You need a filesystem that supports resizing.

You may also make new partitions and use them in a new raid set.

----------

## Havin_it

Thanks srs5694 for the very detailed info!

I don't think it is a hybrid MBR (just jargon FAIL on my part). I don't see any reason it would be; when I setup the disk(s) the goal was just to use GPT partitioning, nothing more complex, and I did use parted as you suspected. gdisk shows the protective MBR only lists sda1.

I'd be fine with making a Bios Boot Partition (I can spare 2MB, just about!) so the only concern for me would be that it wouldn't mess up the RAID volume containing the current sda2. Do you know if using the gdisk "transpose partition numbers" will make the kernel obey the ordering I set, or does it just read the partitions in on-device order anyway?

@Neddy, good to hear - almost sounds like I knew what I was doing  :Wink: 

----------

## srs5694

 *Havin_it wrote:*   

> I'd be fine with making a Bios Boot Partition (I can spare 2MB, just about!) so the only concern for me would be that it wouldn't mess up the RAID volume containing the current sda2. Do you know if using the gdisk "transpose partition numbers" will make the kernel obey the ordering I set, or does it just read the partitions in on-device order anyway?

 

If you're using Linux software RAID, you'd probably need to shrink the RAID partitions on all the partitions in a RAID set if you want to shrink one to make room for a BIOS Boot Partition. This would, of course, also mean shrinking the filesystem or other data structure (LVM or swap space) stored on that RAID set. You might instead want to check for unused space on your disk. If you partitioned your disk(s) with a recent enough version of parted, it probably aligned the partitions on 1MiB boundaries, which means that there's close to 1MiB of unused space at the start of the disk. There might also be unused space at the end of the disk. Either location might be fine for use as a BIOS Boot Partition. (You needn't worry about alignment with these partitions; they're small, they're used only at boot time, and they're seldom written, so performance problems will be unimportant.)

The kernel uses the in-table ordering of partitions, as reported by numbers in gdisk, to determine the device numbers. I'm not sure I understand why you'd want to swap them, but you could do so with gdisk's transpose command if you wanted to.

----------

## Havin_it

Oh, if the price was resizing four RAID partitions I'd definitely give it a miss! But that's not my plan: I'd just trim a bit from the root partition (current sda1, a normal partition) instead. Say I do this at the end of sda1 (easier all round), then the BIOS Boot partition I added would then be sda2 and the actual RAID partition (current sda2) would become sda3, unless I transpose those two.

Of course the SCSI naming of the partitions may not even matter to mdadm; as I mentioned to NeddySeagoon, they do auto-assemble so I reckon it probably doesn't, but I'm not certain.

----------

## NeddySeagoon

Havin_it,

If you shrink sda2 and add sda3 as your BIOS boot partition, sda2 will not change its name.

The partition numbers for partitions 1..4 come from the partition table entry order, not from the space on disk order.

The two need not be the same.

Logical partitions on the other hand are stored in a linked list.  The first one is always 5.

If you have several logical partitions and delete one in the middle of the linked list, the others all move down the name list, sda10 becomes sda9 etc.

The space on disk is not moved so disk space ordering and space on disk ordering soon gets out of step.

----------

## Havin_it

Not shrinking sda2, I'd shrink sda1 but I get your point.

Do I interpret this that if I add the new partition between the existing two, it'll be "born" as sda3 anyway? No need to transpose?

----------

## NeddySeagoon

Havin_it,

You can choose any free partition number ... but yes.

----------

## srs5694

 *NeddySeagoon wrote:*   

> If you shrink sda2 and add sda3 as your BIOS boot partition, sda2 will not change its name.

 

This is true when working with gdisk, and probably with some other tools, but some tools do change the partition numbering when inserting a new partition between two existing partitions. I recommending experimenting with a USB flash drive or in a virtual machine if in doubt about what any given tool will do, if this detail is important. (I suspect it's not important for RAID arrays that auto-assemble, but I'm not positive of that.)

 *Quote:*   

> Logical partitions on the other hand are stored in a linked list.  The first one is always 5.

 

This is also true, but as logical partitions are purely an MBR phenomenon and as Havin_it says the disk is a GPT disk, it's not really relevant.

----------

## elmar283

I have the same problem.

Can anyone tell me how to solve this without first destroying a my partitions first.

I have a gpt partition scheme with:

```

GNU Parted 3.1

Apparaat /dev/sda wordt gebruikt.

Welkom bij GNU Parted!  Typ 'help' voor een opdrachtenoverzicht.

(parted) print                                                            

Model: ATA SanDisk SDSSDP06 (scsi)

Schijf /dev/sda: 64,0GB

Sectorgrootte (logisch/fysiek): 512B/512B

Partitietabel: gpt

Schijfvlaggen: 

Nummer  Begin   Einde   Grootte  Bestandssysteem  Naam     Vlaggen

 1      17,4kB  32,0MB  32,0MB   ext2             primary

 2      32,0MB  1032MB  1000MB   linux-swap(v1)   primary

 3      1032MB  64,0GB  63,0GB   ext4             primary

(parted)                                                    

```

I understand that I need a fourth partition for grub2. 

How do I do that without first deleting partition /dev/sda1?

The errormessage is:

```

grub2-install /dev/sda

/usr/sbin/grub2-bios-setup: waarschuwing: dit GPT-partitielabel bevat geen BIOS-opstartpartitie; inbedding is niet mogelijk.

/usr/sbin/grub2-bios-setup: waarschuwing: Inbedden is niet mogelijk.  GRUB kan in deze configuratie alleen worden geïnstalleerd met bloklijsten.  Bloklijsten zijn echter ONBETROUWBAAR en het gebruik ervan wordt ontraden..

/usr/sbin/grub2-bios-setup: fout: zal niet verder gaan met bloklijsten.

```

----------

## srs5694

Elmar283,

It's almost always best to start a new thread rather than hijack an existing one (even one that's seen no activity for months). Problems that seem on the surface to be related often are not actually related, and trying to solve two different peoples' problems in one thread quickly becomes confusing. Old threads (like this one) may be ignored, and readers may end up confusing the old context as applying to you, when in fact it might not.

That said, you may have gaps in your partition scheme in which you can add a BIOS Boot Partition; it's impossible to tell for sure because the units used by parted by default are too crude. You can either type "unit s" and view the partition table to see it in sectors or use gdisk (in the gptfdisk package) for this task. Post that output to your new thread if you don't see an obvious gap. (The end of the disk is fine, too, BTW; the BIOS Boot Partition does not need to go at the start of the disk.) If there's no existing gap, you can use GParted or the combination of resize2fs and gdisk to resize one of your existing ext*fs partitions; or you can resize your swap partition in a similar way or by deleting it and re-creating it as a slightly smaller partition.

----------

