storaged-project
Request: Add EFI system partition FS type
I'm using udisks2 to partition a disk for my OS installer. I'm trying to format an EFI system partition, which needs to be FAT 32 (the spec only mentions FAT16 is permissible on removable media, which means that in requires FAT32 on permanant storage like an SSD)
Currently, udisks2 formats vfat partitions without specifying the -F argument. This means mks.vfat is allowed to pick an arbitrary FAT size. In practice, it will auto-select FAT32 if the disk is 512MiB or larger, however this behavior is undocumented.
My request: Could udisks2 have a vfat32 or an esp filesystem type, that is just like vfat but it calls mkfs.vfat -F32 ...? As an alternative, perhaps there could be some way to force a FAT size, or to specify arbitrary arguments to the mkfs command (this is probably going to be harder to implement)?
Oh, you mean something like type=efi option for the org.freedesktop.UDisks2.Block.Format() method? This method takes special empty, dos and gpt types, among swap, that are not real filesystems. The rest of the supported types align directly with libblockdev filesystem plugin. This is currently being heavily rewritten in #1005, while keeping the public API unchanged.
This is a rather interesting idea indeed, given that the Format() method can optionally change partition IDs in one go. A couple more checks can be added to ensure the final EFI Boot Partition aligns to specifications.
A request to allow passing arbitrary mkfs arguments is #583 but so far we don't have a clear idea how to merge and validate the resulting arguments together.
I call CreatePartitionAndFormat, but yeah it'd be great if I could specify in some way that I want FAT32 or an EFI-compliant partition. If you're referring to update-partition-type=True being set in the options, then yeah I think it makes sense for the partition type to be set to EFI System (but it shouldn't be done by default, of course)
So the 2.10.0 release will bring an option to supply extra mkfs arguments. I'm not 100% sure about the special efi meta-argument at this moment, might reconsider that the next release cycle.