https://bugzilla.suse.com/show_bug.cgi?id=1169874
https://bugzilla.suse.com/show_bug.cgi?id=1169874#c15
Ancor Gonzalez Sosa
It would be interesting to define a default ordered list of symlinks type if that's not already the case. This list might vary according to the nature of the device.
by-path would probably come at last in the list.
yast2-bootloader already includes such list. First it tries to use the default link configured for storage-ng, that is usually UUID. When that fails, it follows this list: by_label || by_uuid || by_id || by_path || name As explained, the problem here is that some of those links are not available/known before setting up the disks. (In reply to Fabian Vogt from comment #10)
Yes, Storage NG is actually really smart in that area and applies all kinds of selection magic to determine that.
But the logic in yast2-bootloader (explained above) is not fully synchronized with the logic in storage-ng. Is something we failed to unify for SLE-15-SP2 (there are many subtle differences in the way how yast2-bootloader and storage-ng understand the topic). We plan to synchronize all that rather soon-ish for TW. (In reply to Josef Reidinger from comment #13)
So question is what is worse. Possible overwrite user selection or not using uuid/label/others udev links.
In my opinion, overwriting the user selection is worse than skipping some valid options (like UUID). I wouldn't do what is suggested in that pull request. I would rather look for an alternative solution when we finally do the unification (for example, we may consider to enforce the UUID so we know it in advance). -- You are receiving this mail because: You are on the CC list for the bug.