3 ms·
We had that kind of problem because we relied on /dev/disks/by-label
by isodude 5y ago
We had that kind of problem because we relied on /dev/disks/by-label
- heavyset_go 5y agoCan you tell us more about this? How did you determine that that was the problem? What was your solution? I ask because I use /dev/disks/by-label and have never had this problem, and if I ever had to experience it, it would drive me insane.
- sigg3 5y agoI've solved a similarly sounding issue by using the UUID. Get it with blkid, then use UUID="<uuid goes here>" in fstab instead of LABEL="<label>". But this was a long time ago, on a much older systemd (like Fedora 17 or 18).
- dharmab 5y agoThis is a common error even back in the Sysvinit days. /dev/disks/by-label is not guaranteed to map the name labels to disks on every boot, and it can change with boot timing based on the storage controller behavior. Use /dev/disks/by-uuid instead. /dev/disks/by-label is a legacy from the old days of systems with static disks wired in a specific, unchanging configuration.
- heftig 5y agoYou've confused by-label with the kernel's device nodes (e.g. /dev/sda1). Kernel names are assigned in order. Labels are just like UUIDs and part of the filesystem. However, unlike UUIDs they don't necessarily exist, are not as likely to be unique (you should only get duplicate UUIDs by cloning filesystems) and are easier to change. This makes them less suitable for mount configuration.
- isodude 5y agoLong time ago now, but we had disks just unmounting and mounting at free will. As someone said by-label is not stable and could be changed, causing problems. We still use it though but not in customer facing servers where these problems arise. Maybe related to lvm/snapshot etc.