On Tuesday 10 October 2023, Martin Wilck via openSUSE Factory wrote:
On Sun, 2023-10-08 at 08:03 +1300, Michael Hamilton wrote:
Bumping this important thread.
I think the chikens are coming home to roost on this change, there seem to be quite a few people reporting boot issues.
Do you have anything concrete? If yes, please provide links or hints. I'm looking myself, but as there are multiple ways in which people can report issues, I might overlook something.
Thanks, Martin
The main thing that bit me was that the order of /dev/sd* is no longer fixed which caused problems for my boot configuration and drive configuration scripts (hdparm/smartctrl post-boot scripts). 0) My symptom is being unable to boot (I think people reporting slow boots are experiencing a different problem). 1) Make sure /dev/sd* isn't used in /etc/fstab. 2) Check /etc/default/grub, make sure GRUB_DISABLE_LINUX_UUID is commented out (normal case). 3) Check /boot/grub2/grub.cfg and make sure it doesn't reference /dev/sd* in other ways. 4) Track down any scripts that set parameters for any /dev/sd* devices. When dealing with #4 above, I'm not sure what hdparm and smartctrl accept, so for the moment I'm using code that extracts the /dev/sd name from the output of lsscsi command. There is a discussion going on in the forums about how to restore stability to the ordering (for those that don't want to change or want a short term fix), see: https://forums.opensuse.org/t/problem-with-disks-order-after-snapshot-202309... Which suggests adding scsi_mod.async_probe=0 to the bootline. Would this be the same for nvme or does scsi cover that?. The suggestion seems to work. As you suggested, adding udev.scsi_symlink_src=LTVS udev.scsi_id_serial_src=LTVS to the bootline also seems to result in the old ordering being used. With both suggestions above, I haven't done enough boots to be sure of stability of the /dev/sd* assignments. But either is worth a go to get back into the system and fix the /dev/sd* references. Cheers, Michael