As a preface, if I had just read the ArchLinux Wiki Article for fstab instead of skipping it because I thought I knew everything at 4am, I would’ve noticed it explicitly mentioning why you should use UUIDs (or labels).

I used UUIDs for years in my fstab, but recently I went on a mission to encrypt my existing linux install (mostly going in blind with my own technique).

For some unknown reason, I always do stuff like this way past my bedtime, maybe it’s more fun? I don’t know, but what I do know is that that was the start of my downfall.

Once starting the process of debugging the countless mistakes I had made, I ended up swapping to using kernel descriptors (eg: /dev/nvme0n1p1) because I kept seeing them be used in old forum posts and I thought to myself that I should try the same (because I was desparate for something to work, I guess).

Needless to say, It didn’t work. There is no difference using the UUIDs or any other identifier, except the fact that kernel descriptors are bound to change in certain scenarios (eg: Your second drive initialized before your first one because the first one is being slow today or something like that), which will lead to the wrong partition being mounted/used.

I was lucky that this didn’t stop me from fixing my install, it was the next day where the “race condition” described occurred, breaking my boot sequence. It was then that I realised this mistake.

It was probably a good thing too that I wasn’t being booted into a system with all the wrong partitions mounted in root, home, etc, because that may have caused other (potentially more serious) issues. I was instead stopped at the pearly gates with an error, something like: efi mount - bogus number of reserved sectors, can't find valid FAT filesystem. Obvisouly, with hindsight, this was because it was trying to use the wrong partition, but my pea brain at the time was on fire.

The same goes for your crypttab file (or potentially any other hardcoded file that is referencing a kernel descriptor) by the way.