https://bugzilla.suse.com/show_bug.cgi?id=1216070 https://bugzilla.suse.com/show_bug.cgi?id=1216070#c13 --- Comment #13 from Michael Hamilton <michael@actrix.gen.nz> --- (In reply to Martin Wilck from comment #12)
Hm, looking again at https://forums.opensuse.org/t/problem-with-disks-order-after-snapshot- 20230921/169324/13:
lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-0HP_LOGICAL_VOLUME_00000000 -> ../../sdb lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-0HP_LOGICAL_VOLUME_01000000 -> ../../sda lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-0HP_LOGICAL_VOLUME_02000000 -> ../../sdc lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-3600508b1001c21d488c454a46bc39f22 -> ../../sdc lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-3600508b1001c99233458581ffb65cc88 -> ../../sdb lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-3600508b1001cd3e7527deb3b931a6639 -> ../../sda lrwxrwxrwx 1 root root 9 Sep 23 14:44 scsi-SHP_LOGICAL_VOLUME_0014380280B60D0 -> ../../sdb lrwxrwxrwx 1 root root 9 Sep 23 14:44 wwn-0x600508b1001c21d488c454a46bc39f22 -> ../../sdc lrwxrwxrwx 1 root root 9 Sep 23 14:44 wwn-0x600508b1001c99233458581ffb65cc88 -> ../../sdb lrwxrwxrwx 1 root root 9 Sep 23 14:44 wwn-0x600508b1001cd3e7527deb3b931a6639 -> ../../sda
The workaround I suggested in comment 6 won't help here. All these disks are logical volumes on the same controller. No USB is involved.
It's puzzling that the order of these disks changes because some drivers have been converted from built-in to modules, at least at first sight.
My hand-waving guess is that if `ahci`, `scsi_mod` and `sd_mod` are built-in, the sd devices are probed in the order the hardware devices (PCI controllers, SATA ports) are detected, and because the hardware detection takes some time, the probing order appears deterministic (async probing of first sd device is finished before the 2nd SATA port appears, etc). OTOH, if `sd_mod` is a module, it will be requested and loaded by the kernel when ahci detects the first SCSI disk device. The loading will take some time, and it's not unlikely that ahci will have finished probing all hardware before sd_mod is ready to probe devices. These devices will then be probed asynchronously, and consequently the ordering will appear non-deterministic.
If this theory is correct, you should be able to work around the issue by adding sd_mod to /etc/modules-load.d/ (and rebuilding the initrd).
Please test that.
I got a bugzilla needinfo email. Your quote from the forum was from forum-user phil524, I'm not sure they are participating in this bugzilla bug. Are you suggesting this new proposed work around is also applicable more generally to my system? Given the delays due to participants being in different timezones, I will proceed and report back in case that's of any help, so this is what I will shortly do: echo sd_mod > /etc/modules-load.d/sd_mod.conf dracut -f --regenerate-all In respect to timings, looking at the journals: with the modules built-in, logging about /dev/sda happens in the first second of logged messages; where as modules not built in doesn't log anything about /dev/sda until about 3 seconds into the boot and a lot of other things have happened as well by then. BTW, after doing: echo 'softdep usb_storage pre: ahci' >/etc/modprobe.d/10-ahci-scsi.conf dracut -f --regenerate-all three boots have all come up with the same old ordering of /dev/sd* -- You are receiving this mail because: You are on the CC list for the bug.