Allow geom_part schemes to have a different default # entries than minimum.

[will]

Summary

This change is useful primarily for using GPT on embedded boards like the pine64 (and others using an Allwinner SoC) that want a firmware image loaded below sector 34 (8K in that instance).

Test Plan

Use gpart create -s gpt with an -n argument less than 128.

[• lidl]

sys/geom/part/g_part_gpt.c

142

Text that notes setting the number of entries smaller than the 128 partitions minimum violates the EFI specification should be noted in the man page for the command.

Why one would want to violate the specification should also be documented in the man page.

[asomers]

I'm leery of violating the GPT spec just to support broken hardware that was never intended to use GPT. MBR is still an option, and we could put an alternative partition tool in ports that allows screwy noncompliant partition schemes. Do we really need this change?

Judging from https://github.com/longsleep/build-pine64-image/blob/master/simpleimage/platform-scripts/resize_rootfs.sh , it looks like other Pine64 users mostly use MBR partition tables.

[ngie]

I'm leery of this change too... it seems like this is more of a vendor spec implementation bug than anything else, and the vendor needs to go fix their platform(/firmware?)

[• lidl]

I'm not opposed to this change. As I read the change, the default action is to still create EFI compliant GPT tables, with the minimum 128 partitions. I'm OK with the system growing the capability to create non-standards-conforming GPT tables, as long as the default is create conforming tables.

Yes, it stinks that some of the early arm64 variants have this issue, but I'd rather than a working solution (even if it isn't standards compliant) so that early work on these boards can progress, than be pedantically correct and not booting.

Hopefully the Pine64 (and other Allwinner SOC based boards) will get a better implementation in the future, and be able to deal with the boot-block at places other than 8K into the disk device. In the meantime, however, I think we ought to have the ability to work with on the boards.

[imp]

I don't think we should make this change. Having non-standard GPT tables is going to cause problems everywhere that enforces the limits or assumes they are OK. MBR is sufficient for this platform.

sys/geom/part/g_part_gpt.c

142

Make the connection between number of entries and Firmware loader at fixed location (s) on the drive more explicit. Reading this comment makes me go "Huh? what's the connection and why?".

+1 on man page info.

[will]

gpart currently doesn't support MBR with gpart add -t efi. You have to say -t '!239' instead.

Fortunately, gpart tolerates short GPT tables without the change, so instead of using this, I could just generate a pre-canned table and write it directly. Not very user-friendly though.

[ae]

I like the idea about the ability to specify the number of entries when creating the table. This add compatibility with mkimg. Also it would be nice to have ability to change the number of entries for already created tables (GPT, BSD). But I don't like UEFI spec violation. You just don't need to use GPT in described case.

[ae]

It is possible to have GPT with only one available entry, but its size should be not less than 16k. AFAIR, mkimg can create such table, but gpart can not. Also there is ability to change number of entries in BSD scheme using bsdlabel(8), but this impossible for gpart(8).

[brd]

I think trying to hold up the spec is a good idea in theory, but in practice there are going to be lots of cases where it is better to be able to do so. So please go ahead with this change.

[emaste]

I don't think we should make this change. Having non-standard GPT tables is going to cause problems everywhere that enforces the limits or assumes they are OK.

I agree we don't want to have non-standard GPT tables in general, but this change only allows the user to make non-standard tables, it does not cause them to be created by default?