Drive designations changing every reboot when no hardware is changed [duplicate]

If you use the PARTUID, you need to indicate that in fstab by starting the line with PARTUUID= rather than UUID. In the example you give, the system looks for an UUID, not a PARTUID, and indeed did not find a maching one.

Replace UUID= by PARTUUID= and you should be good to go.

Both UUID and PARTUUID are intended to be unique identifiers, one related to the file system, so changing when you reformat the partition, the other to the partition, so associated with the partition itself (won't change when you reformat). Is it better to use the one over the other? It does not matter too much. When you mount a drive yourself in fstab, you need to be well aware what you mount, and at that level it does not matter much whether you use one or another unique identifier.

This gave me an error when I ran findmnt --verify --verbose

It has been already mentioned in the other answer. you have to use PARTUUID=.

More info: How do I use a PARTUUID in fstab?

Now I'm not sure if I should be using that or if I should be using the PARTUUID?

In your case it doesn't really matter. But remember, if you are using MBR, Unlike a regular PARTUUID of a GPT partition, MBR's pseudo PARTUUID can change if the partition number changes. [1]

Why my UUID is so much shorter than other examples that I've seen?

Actual UUIDs are supposed to be 128-bit long and meant to be unique. Prior to this, various systems provided various serial numbers of various size to be distinguishable. So Linux just takes whatever serial it can find and sticks them in the /dev/by-uuid/ directory even if they aren't matching the UUID definition. [2]

As a personal preference I rather to use use UUID. Even when I'm creating an encrypted swap partition. Also there is no PARTUUID for things like lvm. As you might know fstab stands for File System Table. So I guess it's better to use UUID as it's related to the file system. Use UUID and no surprises unless you have to use other methods for specific reasons.

I also found a nice answer at ArchLinux's forum that worth reading: PARTUUID instead UUID in fstab, Pros / Cons ?. Here are some quotes from the answer:

PARTUUID identifies a partition. If you decide to use the partition for something else (format it), it'll still be identified even though the content is no longer there, and it might get mounted to the wrong place.

if your partition table had an issue, and you end up re-creating the same partitions (with different partuuids), it'll no longer be identified even though the content is still there.

Only partitions have PARTUUIDs, you don't have them for other block devices

Mounting by PARTUUID works without initramfs so that'd be an advantage if you wanted to make an initrd-free system.

UUID identifies a filesystem by content. If the UUID is found, the filesystem is there. And it doesn't matter if it's a whole block device, partition, raid, luks or lvm. UUID works on all layers, PARTUUID only for partitions.

In general fstab entries are about mounting specific content to specific locations so identifying by content rather than by partition is more natural. It's a lot more common to use UUIDs.

The downside of UUIDs is that you have to scan all devices for content to find them. After all the UUID could be anywhere. With PARTUUID you only check the partition tables, so it's easier/more performant. But you'd need a ton of block devices for that to make a difference.