I seem to have uncovered some sort of systemd issue with the data.mount service now that I’m using partuuid device paths in fstab. On the very first boot from a fresh image created, the data.mount unit now fails to mount with an error unable to find the device listed in fstab. On subsequent boots everything just works fine.
So initially I thought this was some kind of race condition between udev creating the device path symlinks and the data.mount systemd unit. However I have a service of my own that runs much early in the boot sequence that uses the exact same entry in fstab to check and fix gpt header errors and extend data partition to fill remaining block device on data partition, and this runs just fine every single time irrespective of whether its first boot or subsequent boots.
So as most examples of using partuuid don’t use the udev device path symlink in fstab, but instead use the key value pair notation I re-tested with this, and the problem no longer presented itself. So the use of the udev symlink paths in fstab seem to not fully be supported correctly under some scenarios/implementations. My hunch is there is possibly a bug in systemd/mount-generator that is not resolving the symlink correctly prior to internal usage as less eyes or on the use case, compared to key/value notation in some circumstances.
My proposal is that I provide a pull request to update the partuuid support recently just merged into master to change the fstab entries to use the key/value notation for partuuid use.
Will this cause and issue for any of your tooling that may happen to parse fstab for any reason? The reason I initially went with device paths was incase any tooling expected this field to be a path.