I have a HP server with 3 logical disks initialy defined as #lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
ssda
├─sda1 swap 1 ab7656ab-41e6-41e8-aa16-bbb4ca3c643e
├─sda2 ext4 1.0 Tumbleweed 78cf2dab-782f-467c-b749-1bc362844d10 96G 13% /
└─sda4 ext4 1.0 home dc7675a1-24a2-4ec2-a3a1-458af1b9d1e0 34.8G 74% /home
sdb
├─sdb1 ext4 1.0 srv bf2e6374-cee0-4c18-96b5-851f821ac807 78G 16% /srv
├─sdb2 ext4 1.0 var 4136696f-efbb-4c11-94f4-99aaf7ec32a6 91.9G 1% /var
├─sdb3 ext4 1.0 local 89036c77-2a68-4ad2-9dfd-f950288600fa 18.7G 57% /local
└─sdb4 ext4 1.0 opt 55cafd49-1996-4599-8af6-46fbaf61b5eb 46.5G 0% /opt
sdc
└─sdc1
partition sdc1 238 GB not mounted and used for xen VM
all filesystems are ext4
I Intalled this morning snapshot 20230921.
After reboot with new kernel I had problem with the VM which didn’t start
Looking in fdisk I saw that the disks where swapped
sda was old sdc xen partition
sdb was old sda
sdc was old sdb
The swap partition was also not reachable
I did "shutdown -H now ", restarted the system and the disk order again changed
For a long time disk drivers were built-in and now they are built as modules and loaded on demand. So apparently USB drivers are loaded before HDD drivers.
The order of disk enumeration was never guaranteed to be stable across reboots and you should never rely on it. Why do you think the /dev/disk/by-* exist?
I don’t see how to use the uuid in the xen VM définition storage
hpprol2:/etc/libvirt/storage # cat diskc.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh pool-edit diskc
or other application using the libvirt API.
-->
<pool type='disk'>
<name>diskc</name>
<uuid>480e9674-a615-460f-9410-062907fbc0a8</uuid>
<capacity unit='bytes'>0</capacity>
<allocation unit='bytes'>0</allocation>
<available unit='bytes'>0</available>
<source>
<device path='/dev/sdc'/>
<format type='unknown'/>
</source>
<target>
<path>/dev</path>
</target>
</pool>
hpprol2:/etc/libvirt/storage #
the disk for the VM (sdc) is a raw disk( formated during installation of xen VM) and is not known by-uuid (because it is not mounted?)
Here is my fstab and what I execute to add my usb drive to the correct mount point.
I always use the UUID - it is fail proof since /dev/sd? are dynamically assigned.
I don’t have time to troubleshoot now, but will jump in long enough to note that I also had the problem reported by Phil524 with snapshot 20230921, and had to restore to an earlier snapshot to keep working. On reboot, TW sometimes mixed up disk order with 20230921, or didn’t see some disks at all. I’ve never experienced anything similar on my system with TW or other distros.
I’ll note that I have had this “problem” with Leap 15.4. But I don’t consider it a real problem. I did have to modify one script to work around it. It isn’t just a Tumbleweed problem.
Here I have the disk sdc but not in /dev/disk/by-uuid.
In fact all these files in /dev/disk/by* are just symbolic links to /dev/sd[a-c].
Common advice seems that onlu by-uuid are reliable but I have a problem with sdc1 which is a raw device (not formatted and not present in by-uuid)
Can I be sure that links other than those in /dev/disk/by-uuid are invariable?
(With more troubleshooting time) I think I figured it out, thanks to posts by arvidjaar and others in this thread, and want to share what I learned with other less technically astute TW users:
Until yesterday, I used this command in a script file to open an encrypted disk:
sudo cryptsetup luksOpen /dev/sdb2 encrypteddisk
That suddenly stopped working with the dup to snapshot 20230921.
The script has worked on repeat reboots, with all above-mentioned kernel locks removed and the current TW kernel 6.5.4-1 running. I’ll guess that the post that malcolmlewis linked explains why the so-long tried-and-true script suddenly stopped worked with the arrival of snapshot 20230921.
That is more then logic. UUIDs are part of file systems (and swap spaces). So, no file system: no UUID. But when there is no file system, nothing can be mounted, so no need for an UUID.
And when you are fed-up with UUIDs, you can always add a LABEL to file systems (again: file systems) and use by LABEL. And then (I hope) those LABELs will be of your own, easy to understand, invention.
I agree for filesystem labels seem as reliable as UUIDs and much more easy to use.
What confuses me is for the data by-id there are several records for each partition.
example for /dev/sdb1:
Because there are several variants of “id”. Different tools generate different “id”. As long as they remain stable across reboot, it does not matter which one you use.
