Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can 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.



This 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.


You'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.


I'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).


Long 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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: