I have 2 identical NVMe drives with GPT partitioning and a ext4 Slackware64-15.0 root partition on nvme0n1p1. I'm using the stock huge kernel and lilo. Occasionally the kernel will fail to find the root filesystem because it's looking on the wrong drive (I know this because I tried putting another root partition with a different hostname on nvme1n1p1).

I've tried configuring lilo with standard device names, by-id names, filesystem labels, and GPT partition labels but still get the same behavior. About every 5th boot it looks on the wrong drive.

Please advise on what I'm doing wrong.

The answers you seek are here: https://unix.stackexchange.com/quest...file-with-uuid

Thanks for the suggestion. I've already tried the same things in fstab which I tried in lilo.conf. I also changed some fstab lines in the root partition on nvme1n1p1 so I could see which root partition was being used. That showed the kernel was loading the wrong root so I'm pretty sure the problem is with the kernel (5.15.63) or lilo (24.2) or even the BIOS or hardware (Asrock X570M-Pro4, BIOS 3.70, Ryzen 7 5800X).

Just make sure the IDs used to distinguish the filesystems or partitions are different, and the initrd waited long enough for the disk devices to appear.

I've been using PARTUUID to find the root filesystem for years on a machine with two NVMe disks and it always worked no matter how the device names change.

Thanks for the info. Is an initrd required? I've been using the huge kernel with no initrd. And if required, how do I ensure the initrd waits long enough?

what is output of

nvme1n1
│
├─nvme1n1p1
│ ext4 ee766853-54f7-4bc2-8c39-c923c633de5f 7a8b3ac1-d5ba-40f8-8755-150d3222ca9f
├─nvme1n1p2
│ ext4 9f9e4e88-14ec-4326-99a0-e747bc672911 2d599038-036e-47bb-8bca-e11c064b2cac 3% /bak
└─nvme1n1p3
ext4 e32f346f-fec1-4a70-b0eb-093d1f51c67f 2176153d-daaa-4ce9-86ad-e6d5c4cc4e11
nvme0n1
│
├─nvme0n1p1
│ ext4 de742a0b-85f1-491b-bd5d-10cb8bda58d6 1e28072c-68ed-4ab8-afab-787c6d96407e 73% /
├─nvme0n1p2
│ ext4 469dcefe-5c00-42dd-83b3-ed5908eca91a 36c7156f-0ae0-4c43-b159-bd7ba5624b78 15% /data
└─nvme0n1p3
ext4 ec1220ce-04c4-4dfe-91a1-bf40d5d15716 c0ad8199-4a03-41e9-a7b6-41de375048c7 60% /home

This is all what I would expect when it boots to the correct root. When it doesn't I get a kernel panic rather than a shell so I don't know.

]]
There is /etc/mkinitrd.conf will give a starting point of what modules are needed in the mkinitrd.conf

Thanks to everyone who replied. I settled for the workaround, not really fix, of removing the second NVMe drive and using an external USB gen 2x2 drive instead. That setup is working fine.