Unencrypted hibernation on more than one NVMe disk names resume by filesystem UUID
On an unencrypted install with more than one NVMe disk, a change merged into quattro names resume by filesystem UUID when setup runs again. A machine set up before keeps the kernel name until then. Encrypted installs and hand-edited drop-ins are left alone.
NVMe names follow the order the controllers finish probing, so on a machine with two NVMe disks they can swap between boots. Hibernation setup had written resume= from findmnt's SOURCE column. On an unencrypted install that is the partition's kernel name, such as /dev/nvme0n1p2. Encrypted installs get /dev/mapper/root, which is stable.
A swapped name loses the hibernated session: the initramfs looks for the image on the other disk and cold-boots. On a boot where the names have moved, Hibernate is refused when the resume device is missing or is not an active swap device. The pull request says it was found on an MSI desktop with two NVMe disks, where the install's root came up as one disk's partition while resume= named a partition on the other disk.
The change writes resume=UUID= followed by the filesystem UUID, and it keeps /dev/mapper names as they are. A machine set up before keeps its kernel name until hibernation setup runs again. That rerun renames the device in the line setup itself writes and rebuilds the boot image. Hand-edited drop-ins, encrypted installs and drop-ins that already name a UUID are left alone.
Version 4.0.6 is the latest release.
Correction
The headline now says unencrypted hibernation on more than one NVMe disk names resume by filesystem UUID. It had also said that a machine set up before keeps the kernel name until setup runs again, and that a hand-edited drop-in is left alone after that; those two limits stay in the summary.