[systemd-devel] systemd-repart MountPoint fails for esp partitions

[serenissi]

This is about fs UUID, not GPT PARTUUID. vfat filesystems do not support 
standard UUID format for historical reason.

On 4/2/25 14:32, Karel Zak wrote:
> On Tue, Mar 25, 2025 at 09:00:09PM -0600, Thayne Harbaugh wrote:
>> Response in-line:
>>
>> On Tue, 2025-03-25 at 16:53 -0600, Thayne Harbaugh wrote:
>>> Greetings,
>>>
>>> systemd-repart MountPoint fails to generate a correct fstab entry for
>>> esp partitions.  It generates a standard partition UUID which does
>>> not
>>> work for FAT file systems - a FAT volume ID must be used analogous to
>>> what is generated for vfat in mkfs-util.c:make_filesystem().  The FAT
>>> volume ID is in the form of 32 bits of uppercase hex digits with a
>>> dash "-" between the high and low 16 bits: XXXX-XXXX (where X
>>> represents an uppercase hex digit).
>>>
>>> Attached is a patch I have been using with systemd v257 to provide
>>> correct behavior.
>> Something did not like the .patch attachment - here it is in-line:
>>
>>
>>
>> Use the PARTUUID to mount ESP partitions
>>
>> The ESP vfat partition fails to mount because the UUID generated by repart
>> matches neither the vfat serial number (although it's somewhat comparable) nor
>> the partition UUID.
> I don't understand this. I thought that ESP is a partition on GPT and
> all GPT partitions have UUIDs (aka PARTUUID). Why, in this case, do we
> need to generate a UUID based on the filesystem? Do you want to
> address the partition or filesystem in the fstab?
>
>      Karel
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250402/9fcd63a2/attachment.sig>