Re-stabilizing the order of /dev/sd* devices
The discussion on the previous thread "SCSI device identification and SCSI symlink generation in sg3_utils 1.48" [1], the openSUSE Forum [2], bugzilla [3] has revealed that with one exception, the problems that users encountered had not been caused by the sg3_utils update, but by the almost simultaneous update of the TW kernel to 6.5.4, which changed scsi_mod and sd_mod from built-in to loadable modules. In the course of this discussion, the idea came up to stabilize the ordering of sd devices by loading sd_mod before any SCSI low level drivers, using a softdep. I have implemented this now in [4]. I would be grateful for testing this package on a variety of systems. I already tried a few, and saw no issues. Currently TW only. The expected effect is that the ordering of sd devices stabilizes again (if you test this, please undo manual workarounds that you may have applied so far). On systems with only NVMe hardware (e.g. laptops with M.2 SSDs) where multipath-tools is not installed (if you aren’t using dm-multipath, you can just uninstall it with “zypper rm multipath- tools”), an additional expected effect is that the system would come up without any SCSI drivers loaded (check /proc/modules). If an USB stick or some other SCSI device is added to such a system, SCSI modules should be loaded on demand, and the stick should be mounted as usual. Feedback very welcome. I plan to submit this to factory next week. Regards, Martin [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/Y... [2] https://forums.opensuse.org/t/problem-with-disks-order-after-snapshot-202309... [3] https://bugzilla.suse.com/show_bug.cgi?id=1216070 [4] https://download.opensuse.org/repositories/home:/mwilck:/suse-module-tools/o...
On 25. 10. 23, 22:45, Martin Wilck via openSUSE Factory wrote:
The discussion on the previous thread "SCSI device identification and SCSI symlink generation in sg3_utils 1.48" [1], the openSUSE Forum [2], bugzilla [3] has revealed that with one exception, the problems that users encountered had not been caused by the sg3_utils update, but by the almost simultaneous update of the TW kernel to 6.5.4, which changed scsi_mod and sd_mod from built-in to loadable modules.
In the course of this discussion, the idea came up to stabilize the ordering of sd devices by loading sd_mod before any SCSI low level drivers, using a softdep. I have implemented this now in [4]. I would be grateful for testing this package on a variety of systems. I already tried a few, and saw no issues.
Currently TW only.
The expected effect is that the ordering of sd devices stabilizes again (if you test this, please undo manual workarounds that you may have applied so far). On systems with only NVMe hardware (e.g. laptops with M.2 SSDs) where multipath-tools is not installed (if you aren’t using dm-multipath, you can just uninstall it with “zypper rm multipath- tools”), an additional expected effect is that the system would come up without any SCSI drivers loaded (check /proc/modules). If an USB stick or some other SCSI device is added to such a system, SCSI modules should be loaded on demand, and the stick should be mounted as usual.
Feedback very welcome. I plan to submit this to factory next week.
Hi, why should we care at all? Using /dev/sd* in fstab is broken for years. So anyone using that should be forced to fix it for good and not find workarounds. Or am I missing something? thanks, -- js suse labs
On Thu, 2023-10-26 at 06:50 +0200, Jiri Slaby wrote:
why should we care at all?
My main motivation behind this actually something different. I dislike the fact that we have been statically loading several SCSI modules, always, on every system. It contradicts the concept of loadable modules - if we always load module X, why not make it a built-in in the first place? This change will allow us to cease loading the SCSI modules on every system early during boot, and this makes our distribution a wee little bit leaner, cleaner, and better, IMO. I've wanted to do this for years, and the only reason we haven't done it is that Factory had the scsi modules built-in, and we wanted no difference between Factory and SLE/Leap in this respect.
Using /dev/sd* in fstab is broken for years. So anyone using that should be forced to fix it for good and not find workarounds. Or am I missing something?
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect. Perhaps the subject I chose for this post was misleading and ill- chosen, sorry for that. I was thinking about the users that had complained previously. The discussion that I linked in my previous post has shown that some TW users have been relying on the ordering, and haven't seen issues until scsi_mod and sd_mod were converted to loadable modules in 6.5.4. I think that our previous assessment of the instability of the /dev/sd* assignments has been incomplete. We used to say that it's caused by asynchronous probing. That's part of the picture, sure, and it matters a lot on large systems with hundreds of LUNs. But on typical small systems, it's not the main factor. What matters there is the ordering in which drivers are loaded, and in which each individual driver probes it's devices. This is the outcome of bsc#1216070. * If sd_mod is loaded before the low-level drivers (ahci and usb- storage on typical workstations), the sd devices will be probed in the order in which the SATA and USB devices appear on their respective buses, providing a certain extent of perceived determinism, because hardware device probing is often done sequentially and takes a couple of milliseconds per device, and the sd device appears instantaneously after the low-level device. * OTOH, if sd_mod is loaded on demand when the first SCSI device matching its modalias is found, there will be a couple of LLD devices already when sd_mod is fully initialized, and the ordering of those will appear to be "random". This is the effect that users have seen with 6.5.4, and I see no reason not to revert it. It's achieved by an innocent "softdep scsi_mod post: sd_mod", and it's hard to perceive a negative impact of this softdep. Systems that have SCSI devices but no SCSI disks are very rare these days. Thanks Martin
On Thursday 2023-10-26 09:31, Martin Wilck via openSUSE Factory wrote:
On Thu, 2023-10-26 at 06:50 +0200, Jiri Slaby wrote:
why should we care at all?
My main motivation behind this actually something different. I dislike the fact that we have been statically loading several SCSI modules, always, on every system. It contradicts the concept of loadable modules - if we always load module X, why not make it a built-in in the first place?
Isn't this how openSUSE has worked most of its history? It feels like sd_mod was built-in, because everyone needed it (be it for SATA, SCSI or USB). Now that SATA is getting replaced by NVME, there is less of a use for sd_mod.
On Thu, 2023-10-26 at 09:43 +0200, Jan Engelhardt wrote:
On Thursday 2023-10-26 09:31, Martin Wilck via openSUSE Factory wrote:
On Thu, 2023-10-26 at 06:50 +0200, Jiri Slaby wrote:
why should we care at all?
My main motivation behind this actually something different. I dislike the fact that we have been statically loading several SCSI modules, always, on every system. It contradicts the concept of loadable modules - if we always load module X, why not make it a built-in in the first place?
Isn't this how openSUSE has worked most of its history? It feels like sd_mod was built-in, because everyone needed it (be it for SATA, SCSI or USB). Now that SATA is getting replaced by NVME, there is less of a use for sd_mod.
Thanks, you have just nicely re-phrased my intention :-) Martin
On 26.10.23 09:31, Martin Wilck via openSUSE Factory wrote:
My main motivation behind this actually something different. I dislike the fact that we have been statically loading several SCSI modules, always, on every system. It contradicts the concept of loadable modules - if we always load module X, why not make it a built-in in the first
IIRC the motivation behind that was allowing a replacement of the modules without updating the whole kernel.
place? This change will allow us to cease loading the SCSI modules on every system early during boot, and this makes our distribution a wee little bit leaner, cleaner, and better, IMO.
Good.
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect.
I am afraid this has an inherent problem. Any scheme that goes by an attribute needs those attributes to be a) unique b) present If you wish to use a UUID, you are basically addressing the _medium_, not the device. I am afraid doing the big stuff makes you forget the difference. We need true device names on occasion. That requirement is not going to go away. Regards Oliver
On Thu, 2023-10-26 at 11:16 +0200, Oliver Neukum wrote:
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect.
I am afraid this has an inherent problem. Any scheme that goes by an attribute needs those attributes to be
a) unique b) present
If you wish to use a UUID, you are basically addressing the _medium_, not the device. I am afraid doing the big stuff makes you forget the difference.
We need true device names on occasion. That requirement is not going to go away.
We have unique device IDs for most modern hardware, for example SCSI NAA IDs, NVMe WWIDs, or ATA and USB IDs. You are right that sometimes these attributes aren't present, perhaps because of some IO error during device probing and/or udev processing, or because the manufacturer didn't bother. But these are fortunately rare situations. Virtual devices are a different issue, I am not sure if all emulators take care to generate trustworthy unique IDs. Martin
Regards Oliver
On Thursday 2023-10-26 11:16, Oliver Neukum via openSUSE Factory wrote:
Any scheme that goes by an attribute needs those attributes to be
a) unique b) present
If you wish to use a UUID, you are basically addressing the _medium_, not the device.[..] We need true device names on occasion.
What "true" anyway, one would wonder
On 26.10.23 11:44, Jan Engelhardt wrote:
On Thursday 2023-10-26 11:16, Oliver Neukum via openSUSE Factory wrote:
If you wish to use a UUID, you are basically addressing the _medium_, not the device.[..] We need true device names on occasion.
What "true" anyway, one would wonder
True in that regard is a name that is a) based on a path b) refers to a device as opposed to a medium To illustrate my point: /dev/disk/by-path pci-0000:02:00.0-nvme-1 pci-0000:02:00.0-nvme-1-part4 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi-0:0:0:3 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:3 pci-0000:02:00.0-nvme-1-part1 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi-0:0:0:0 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:0 pci-0000:02:00.0-nvme-1-part2 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi-0:0:0:1 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:1 pci-0000:02:00.0-nvme-1-part3 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi-0:0:0:2 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:2 /dev/disk/by-uuid/ 6b557439-a722-46c6-b9fa-e3395a5f4d40 722799ab-821e-4921-9c20-f97d284ca32e 9C52-D41D fe8a60ac-2e5b-4090-a9eb-d68149568dfb A lot of devices (not media) that exist and need to be referred to somehow. Regards Oliver
On Thu, 2023-10-26 at 12:32 +0200, Oliver Neukum wrote:
True in that regard is a name that is
a) based on a path b) refers to a device as opposed to a medium
To illustrate my point:
/dev/disk/by-path pci-0000:02:00.0-nvme-1 pci-0000:02:00.0-nvme-1- part4 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:3 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:3 pci-0000:02:00.0-nvme-1-part1 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:0 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:0 pci-0000:02:00.0-nvme-1-part2 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:1 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:1 pci-0000:02:00.0-nvme-1-part3 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:2 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:2
/dev/disk/by-uuid/ 6b557439-a722-46c6-b9fa-e3395a5f4d40 722799ab-821e-4921-9c20- f97d284ca32e 9C52-D41D fe8a60ac-2e5b-4090-a9eb-d68149568dfb
A lot of devices (not media) that exist and need to be referred to somehow.
And you don't see by-id links for these? Martin
On 26.10.23 17:03, Martin Wilck wrote:
On Thu, 2023-10-26 at 12:32 +0200, Oliver Neukum wrote:
True in that regard is a name that is
a) based on a path b) refers to a device as opposed to a medium
To illustrate my point:
/dev/disk/by-path pci-0000:02:00.0-nvme-1 pci-0000:02:00.0-nvme-1- part4 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:3 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:3 pci-0000:02:00.0-nvme-1-part1 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:0 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:0 pci-0000:02:00.0-nvme-1-part2 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:1 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:1 pci-0000:02:00.0-nvme-1-part3 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:2 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:2
/dev/disk/by-uuid/ 6b557439-a722-46c6-b9fa-e3395a5f4d40 722799ab-821e-4921-9c20- f97d284ca32e 9C52-D41D fe8a60ac-2e5b-4090-a9eb-d68149568dfb
A lot of devices (not media) that exist and need to be referred to somehow.
And you don't see by-id links for these?
Yes, I have them, but look at how they are constructed. They are (showing all for comparison): nvme-eui.ace42e00060644b22ee4ac0000000001 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part4 nvme-eui.ace42e00060644b22ee4ac0000000001-part1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part2 usb-Generic_USB_CF_Reader_058F312D81B1-0:1 nvme-eui.ace42e00060644b22ee4ac0000000001-part2 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part3 usb-Generic_USB_CF_Reader_058F312D81B1-0:1-part1 nvme-eui.ace42e00060644b22ee4ac0000000001-part3 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part4 usb-Generic_USB_MS_Reader_058F312D81B1-0:3 nvme-eui.ace42e00060644b22ee4ac0000000001-part4 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part1 usb-Generic_USB_SD_Reader_058F312D81B1-0:0 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part2 usb-Generic_USB_SM_Reader_058F312D81B1-0:2 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part3 usb-Generic_USB_SM_Reader_058F312D81B1-0:2. That is taking the path as ID. We are presenting the path and the vendor - Bus 004 Device 005: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader - as id. That does not change the core problem. The only unique information about a device that we'll always have is the path. Regards Oliver
On Mon, Oct 30, 2023 at 09:56:22AM +0100, Oliver Neukum via openSUSE Factory wrote:
On 26.10.23 17:03, Martin Wilck wrote:
On Thu, 2023-10-26 at 12:32 +0200, Oliver Neukum wrote:
True in that regard is a name that is
a) based on a path b) refers to a device as opposed to a medium
To illustrate my point:
/dev/disk/by-path pci-0000:02:00.0-nvme-1 pci-0000:02:00.0-nvme-1- part4 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:3 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:3 pci-0000:02:00.0-nvme-1-part1 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:0 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:0 pci-0000:02:00.0-nvme-1-part2 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:1 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:1 pci-0000:02:00.0-nvme-1-part3 pci-0000:06:00.3-usb-0:1.3.4:1.0-scsi- 0:0:0:2 pci-0000:06:00.3-usbv2-0:1.3.4:1.0-scsi-0:0:0:2
/dev/disk/by-uuid/ 6b557439-a722-46c6-b9fa-e3395a5f4d40 722799ab-821e-4921-9c20- f97d284ca32e 9C52-D41D fe8a60ac-2e5b-4090-a9eb-d68149568dfb
A lot of devices (not media) that exist and need to be referred to somehow.
And you don't see by-id links for these?
Yes, I have them, but look at how they are constructed. They are (showing all for comparison):
nvme-eui.ace42e00060644b22ee4ac0000000001 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part4 nvme-eui.ace42e00060644b22ee4ac0000000001-part1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part2 usb-Generic_USB_CF_Reader_058F312D81B1-0:1 nvme-eui.ace42e00060644b22ee4ac0000000001-part2 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part3 usb-Generic_USB_CF_Reader_058F312D81B1-0:1-part1 nvme-eui.ace42e00060644b22ee4ac0000000001-part3 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part4 usb-Generic_USB_MS_Reader_058F312D81B1-0:3 nvme-eui.ace42e00060644b22ee4ac0000000001-part4 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part1 usb-Generic_USB_SD_Reader_058F312D81B1-0:0 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part2 usb-Generic_USB_SM_Reader_058F312D81B1-0:2 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part3
usb-Generic_USB_SM_Reader_058F312D81B1-0:2. That is taking the path as ID. We are presenting the path and the vendor - Bus 004 Device 005: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader - as id. That does not change the core problem. The only unique information about a device that we'll always have is the path.
The path is not stable either. USB and PCI devices can be plugged into a different port. Device order is not fixed - that's the very reason why sdX name is not stable. I would expect that the numbering of USB ports on a hub depends on the driver enumerating them and rarely changes. On the other hand, the order of the hubs and bus numbering would be arbitrary depending on device probe order. The PCI port order probably depends on some firmware table describing the PCI topology, and can potentially change with BIOS update. Thanks Michal
On Mon, 2023-10-30 at 09:56 +0100, Oliver Neukum wrote:
A lot of devices (not media) that exist and need to be referred to somehow.
And you don't see by-id links for these?
Yes, I have them, but look at how they are constructed. They are (showing all for comparison):
nvme-eui.ace42e00060644b22ee4ac0000000001 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part1 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part4 nvme-eui.ace42e00060644b22ee4ac0000000001-part1 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part2 usb- Generic_USB_CF_Reader_058F312D81B1-0:1 nvme-eui.ace42e00060644b22ee4ac0000000001-part2 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part3 usb- Generic_USB_CF_Reader_058F312D81B1-0:1-part1 nvme-eui.ace42e00060644b22ee4ac0000000001-part3 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1-part4 usb- Generic_USB_MS_Reader_058F312D81B1-0:3 nvme-eui.ace42e00060644b22ee4ac0000000001-part4 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part1 usb- Generic_USB_SD_Reader_058F312D81B1-0:0 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part2 usb- Generic_USB_SM_Reader_058F312D81B1-0:2 nvme-SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G_1 nvme- SKHynix_HFS512GD9TNI-L2B0B_CS0AN73541VA1AL6G-part3
usb-Generic_USB_SM_Reader_058F312D81B1-0:2. That is taking the path as ID. We are presenting the path and the vendor - Bus 004 Device 005: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader - as id. That does not change the core problem. The only unique information about a device that we'll always have is the path.
I can't follow. Both the eui (ace42e00060644b22ee4ac0000000001) and the serial number (CS0AN73541VA1AL6G) should be unique. For large storage arrays, the serial number might not be, but the eui should. Martin
On Thu, 2023-10-26 at 06:50 +0200, Jiri Slaby wrote:
why should we care at all?
...
Using /dev/sd* in fstab is broken for years. So anyone using that should be forced to fix it for good and not find workarounds. Or am I missing something?
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect.
I think some care is is waranted... In principle, /dev/sd* has not been stable for decades, but in practice, for many, especially those with simple desktops, it's been stable since the beginning. The default actual-experience has just now changed. Plus there are other reasons to care... There are heaps of examples of using df, lsblk, smartctl, hdparm, etcetera, that don't mention the instability of /dev/sd*. If anyone has baked those examples that scripts they would have worked nicely until the recent change. It would also be useful if people were able to give desktop advice that isn't perturbed by potential instabilities. Imagine giving advice on manually formatting a file-system, but unbeknownst to the advice-giver, the user has rebooted since posting the question. One could always preface such advice with prerequisites and explanations concerning /dev/sd* and it instabilities, but how many actually do? Then there's the day when one misreads the output from lsblk or similar, or fails to remember that you've booted since last running it. Stability makes that kind of accident a little lest likely - a nice to have unless you have a strong preference for school of hard knocks. I stress I'm writing more from the point of keeping things simple for the small desktop user. For the reasons outlined above, I think stability for that kind of user is good to have, especially if it can be achieved relatively easily. Michael
Hello, On 2023-10-26 22:26, Michael Hamilton wrote:
...
Using /dev/sd* in fstab is broken for years. So anyone using that should be forced to fix it for good and not find workarounds. Or am I missing something?
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect.
I think some care is is waranted...
In principle, /dev/sd* has not been stable for decades, but in practice, for many, especially those with simple desktops, it's been stable since the beginning.
Not only "simple desktops" but also zillions of "simple virtual machines" where the admin knows "for sure" that "the only disk" is /dev/sda. In practice it causes "interesting user experience" when booting from USB disk results that this one becomes /dev/sda and the system disk becomes /dev/sdb. In theory, theory and practice are the same. In practice, they are not. I think the difference here is what should be used in persistent config files (so /dev/sda in fstab is bad) versus what users and admins are used to use when they "just do something", for example typing device names when calling command line tools. I do very much appreciate it to not needlessly cause annoyance for users and admins out there in practice. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nuernberg)
On Fri, 2023-10-27 at 09:25 +0200, Johannes Meixner wrote:
In practice it causes "interesting user experience" when booting from USB disk results that this one becomes /dev/sda and the system disk becomes /dev/sdb.
usb-storage is a low level SCSI driver like any other. If there are multiple LLDs, the disk ordering will depend on the order in which the LLDs are loaded an initialized. If you create an initrd for booting from USB, this initrd must contain "usb-storage". If you want your sd device ordering to remain stable when booting from the USB device, you must make sure that the driver for your "normal" boot disk (e.g. ahci) is also included the initrd, _and_ is loaded _before_ usb-storage. The first requirement can be fulfilled by using "--add-drivers ahci" on the dracut command line. The second would be achieved by creating a modprobe.d file like this: softdep usb-storage pre: ahci and making sure it's included in the initrd, too. As distribution, we can't enforce this automatically. We would have to create softdeps like this for every SCSI LLD. This would imply that loading usb-storage would pull in dozens of unnecessary SCSI drivers on every system. We can't do this. Therefore, if a user creates a USB boot disk for his system, he must take care of the above steps himself, specifying the drivers that his particular system needs in the softdep directive. Note that in order for this to be reliable (too the extent possible), sd_mod should be loaded before all LLDs, as enforced by the forthcoming suse-module-tools update. Thanks Martin
On Fri, 2023-10-27 at 10:40 +0200, Martin Wilck wrote:
softdep usb-storage pre: ahci
Correction: openSUSE ships a default softdep for usb-storage in /usr/lib/modprobe.d/70-softdep-usb_storage.conf. Because modprobe supports only one softdep per module, the existing softdep must be modified / overridden rather than creating a new one. So what you need to do is cat >/etc/modprobe.d/70-softdep-usb_storage.conf <<EOF softdep usb_storage pre: ahci post: uas EOF Regards Martin
participants (7)
-
Jan Engelhardt -
Jiri Slaby -
Johannes Meixner -
Martin Wilck -
Michael Hamilton -
Michal Suchánek -
Oliver Neukum