Thanks so much for elaborating, sckevyn.
It was my mistake to assume that we were talking about GPT or GPT+MBR disks. There, every HFS+ and NTFS partition has a UUID, at least on my system:
root@blue ~# for part in `diskutil list | sed -En 's/.*(disk0s.)/\1/p'`; do echo ${part}: `diskutil info $part | grep UUID`; done
disk0s1:
disk0s2: Volume UUID: 302F82E3-D05F-38A1-BFF8-439CD0E69BAF
disk0s3: Volume UUID: 8A5DD1EC-0BE1-3E17-836C-1BC21FECA7DB
disk0s4: Volume UUID: A020FA1E-97D4-4341-BEE6-81BBBD513FBF
disk0s5:
disk0s1 is the EFI partition (FAT32) and disk0s5 is a ZFS slice, neither of which can currently be used as a system partition.
So for GPT disks, it should indeed be a cosmetic change (given that you are able to read the UUID, but I think you seem to be passing "boot-uuid=<UUID>" to the kernel when the user selects a disk, so it should be there).
However, if a disk is only MBR formatted, it's up to the filesystem to provide a UUID for the partition it lives in. Most popular UNIX filesystems (ReiserFS, ext2/3, JFS, XFS, and probably ZFS on Open Solaris) support that.
Windows (FAT32/NTFS) is a different story. Still, the Linux kernel somehow provides UUIDs for even those partitions (at /dev/disk/by-uuid/).
A hybrid way could be to let "Hide Partition" be a dictionary that has as siblings
- for GPT disks: An array of UUIDs
- for MBR disks: A string with the disk's UUID from the MBR plus an array of partition numbers.
Thanks,
zhell