If you're using UUIDs in GRUB in combination with backups via LVM snapshots you might run into trouble, which I happened to learn the hard way recently.
Consider you have a line like this in your grub.cfg
linux /vmlinuz-linux root=UUID=d24c64f2-3b48-4dce-ac16-344150d0a57a rw quiet
and your root filesystem resides on an LVM volume of which you take an LVM snapshot (e.g. in order to make a block-level backup)
$ lvcreate -n root-snap -L 1G -s /dev/vg0/root
This creates a block-level-identical copy of the root volume, making a new filesystem appear that bears the same UUID as the root filesystem:
$ lsblk /dev/vg0/root /dev/vg0/root-snap
/dev/vg0/root: LABEL="root" UUID="d24c64f2-3b48-4dce-ac16-344150d0a57a" (...) TYPE="btrfs"
/dev/vg0/root-snap: LABEL="root" UUID="d24c64f2-3b48-4dce-ac16-344150d0a57a" (...) TYPE="btrfs"
Now if your machine crashes or freezes while working with the snapshot, the latter will remain throughout reboot and the initramfs can decide to pick the root filesystem on the snapshot over the original one to boot from.
The nasty thing about this is that you are very unlikely to even notice this, as systemd can bring up the system with readonly root filesystem very well (an important feature for embedded systems!). In my case, I was working on the machine for more than an hour until I noticed that there must be something wrong.
So how can we avoid this?
Well, by telling GRUB (or better: the GRUB configuration generator script) to not use UUIDs for rootfs selection:
# /etc/default/grub
(...)
GRUB_DISABLE_LINUX_UUID=true
This way, the boot entry will have the real volume node as path instead of the UUID construct
linux /vmlinuz-linux root=/dev/mapper/vg0-root rw quiet
In this case (root on LVM) this does not break the rule of not relying on kernel device naming schema, as the mapper node will be the same no matter what number the underlying block device has got.