bsdinstall: increase EFI partition size to 200MB

[emaste]

Summary

A larger EFI file system size will facilitate multi-boot configurations and the installation other EFI applications like firmware update tools. 200MB matches OS X.

Note that this changes only the partition size, not the file system that bsdinstall places there. We need to do both, but as the partition size is difficult to adjust later make this change for now so that at least systems installed with FreeBSD 11.0 have a partition layout with room to grow.

[andrew]

Would it be better to make it a constant in a header file? I would expect we would want it the same on x86 and arm64.

[allanjude]

In D6935#145511, @andrew wrote:

Would it be better to make it a constant in a header file? I would expect we would want it the same on x86 and arm64.

Agreed

[nwhitehorn]

Doesn't this still copy an 800K FAT partition onto the 200MB EFI partition? Doing that works, but it doesn't really seem to meet the goals here. It also wastes a ton of space on VMs. When we went with the 800K partition, the concept was that you could have multiple EFI partitions for such circumstances, which is allowed by the standard, or hand-manage it if you want to do multi-boot.

[emaste]

Would it be better to make it a constant in a header file? I would expect we would want it the same on x86 and arm64.

Yes, just in the lead-up to 11.0 I want to keep changes as small as possible, and the current x86 default is unusably small for certain use cases.

[nwhitehorn]

Thanks for the clarification. I'm a little worried about the VM case (it seems silly to have a 300 MB base system + a 200 MB EFI partition that is empty save for a single 75KB executable) but have no serious objection to this change.

[imp]

Let me +100 this. We moved to a 100MB size in our provisioning tools because 800k is just too small.

[imp]

In D6935#145555, @nwhitehorn wrote:

Thanks for the clarification. I'm a little worried about the VM case (it seems silly to have a 300 MB base system + a 200 MB EFI partition that is empty save for a single 75KB executable) but have no serious objection to this change.

In the VM case, EFI partitions aren't involved at all. There shouldn't even be one.

[imp]

In D6935#145572, @imp wrote:

In D6935#145555, @nwhitehorn wrote:

Thanks for the clarification. I'm a little worried about the VM case (it seems silly to have a 300 MB base system + a 200 MB EFI partition that is empty save for a single 75KB executable) but have no serious objection to this change.

In the VM case, EFI partitions aren't involved at all. There shouldn't even be one.

Oh, wait, that's a different case.

[markj]

FWIW, Isilon has needed to increase the ESP size drastically on 4Kn drives. A valid FAT32 filesystem must contain at least 64K clusters, and a 4K cluster size forces the ESP to be slightly larger than 256MB. Otherwise our BIOS considers the filesystem to be corrupt and won't use it. FreeBSD's boot1.efifat image works without modification though - the BIOS seems to go off the size of the ESP's entry in the GPT.

[allanjude]

In D6935#145588, @markj wrote:

FWIW, Isilon has needed to increase the ESP size drastically on 4Kn drives. A valid FAT32 filesystem must contain at least 64K clusters, and a 4K cluster size forces the ESP to be slightly larger than 256MB. Otherwise our BIOS considers the filesystem to be corrupt and won't use it. FreeBSD's boot1.efifat image works without modification though - the BIOS seems to go off the size of the ESP's entry in the GPT.

This might be because, iirc, boot1.efifat is actually fat16

[allanjude]

In D6935#145555, @nwhitehorn wrote:

Thanks for the clarification. I'm a little worried about the VM case (it seems silly to have a 300 MB base system + a 200 MB EFI partition that is empty save for a single 75KB executable) but have no serious objection to this change.

It is not exposed in the function the way it is setup now, but maybe in the future when I am redesigning this bit of the installer as discussed in D6232 it would be possible to use a smaller size if the target disk is under say 20GB, but use the 200MB size if it is larger.

[emaste]

Doesn't this still copy an 800K FAT partition onto the 200MB EFI partition? Doing that works, but it doesn't really seem to meet the goals here. It also wastes a ton of space on VMs. When we went with the 800K partition, the concept was that you could have multiple EFI partitions for such circumstances, which is allowed by the standard, or hand-manage it if you want to do multi-boot.

Right now it does indeed install an 800K FAT partition on the EFI partition, and I hope to address that later on; my primary goal is to have the installer not leave a slew of 800K EFI partitions in its wake that can't be easily updated later on. The default of 800K + additional partitions after it filling up the entire disk makes it hard to add a new partition or grow it post-install.

[allanjude]

In D6935#145594, @emaste wrote:

Doesn't this still copy an 800K FAT partition onto the 200MB EFI partition? Doing that works, but it doesn't really seem to meet the goals here. It also wastes a ton of space on VMs. When we went with the 800K partition, the concept was that you could have multiple EFI partitions for such circumstances, which is allowed by the standard, or hand-manage it if you want to do multi-boot.

Right now it does indeed install an 800K FAT partition on the EFI partition, and I hope to address that later on; my primary goal is to have the installer not leave a slew of 800K EFI partitions in its wake that can't be easily updated later on. The default of 800K + additional partitions after it filling up the entire disk makes it hard to add a new partition or grow it post-install.

I agree that reserving the space is a good idea. This is why we do 512kb for freebsd-boot now, instead of 64kb, and it turned out to be a good idea.

[markj]

In D6935#145590, @allanjude wrote:

In D6935#145588, @markj wrote:

FWIW, Isilon has needed to increase the ESP size drastically on 4Kn drives. A valid FAT32 filesystem must contain at least 64K clusters, and a 4K cluster size forces the ESP to be slightly larger than 256MB. Otherwise our BIOS considers the filesystem to be corrupt and won't use it. FreeBSD's boot1.efifat image works without modification though - the BIOS seems to go off the size of the ESP's entry in the GPT.

This might be because, iirc, boot1.efifat is actually fat16

Oh, huh. It actually appears to be FAT12, which is limited to 4086 clusters. It seems our BIOS is assuming FAT32 though.