Bugzilla – Bug 1212098
YaST Partitioner: Changing the Volume Label of a Mounted Partition
Last modified: 2023-06-12 09:34:06 UTC
This came as observations during manual testing when fixing L3 bug #1211337. See also https://github.com/yast/yast-storage-ng/pull/1340 for the test setup. When using the YaST partitioner to change a volume label of a mounted partition, there are subtle problems that sometimes can lead to severe problems like being unable to mount the root filesystem during boot: (1) Changing the volume label of a mounted ext4 filesystem can silently fail: There is no error, but the label simply stays the same. (2) When using mount by label in /etc/fstab, the label used there remains unchanged rather than consistently doing the change both in the system and in /etc/fstab. The symlinks in /dev/disk/by-label may be changed, but /etc/fstab still has the old one. (3) When the change failed silently (see (1)), the symlink in /dev/disk/by-label may still point to the previous volume label, but the partitioner (incorrectly) shows the new changed volume label after applying the (non-functional) change, terminating and restarting. (4) Btrfs subvolumes may not be able to be mounted; that was prevented by the PR above, but that was a hot fix for the symptom, not the cause. (5) The label of an active swap space cannot be changed; it needs to be deactivated ("swapoff") first. That was also prevented by the PR above. (6) In similar situations, we offer to unmount a filesystem before doing any changes. That does not work for changing the volume label. (7) Changing the volume label of an unmounted filesystem is not possible at first; you have to change it to "mount" in the UI to be able to get to the "fstab options" dialog. There you can change the volume label and then immediately switch the partition back to "do not mount", but that is not at all obvious to the user. It takes some experimenting to find out that solution.
Arvin, (3) may be relevant for libstorage-ng. Sometimes there seems to be a difference between the symlink targets in /dev/disk/by-label and what libstorage-ng reports.
I can confirm (1). For btrfs this is already known, see bug #1143795. (3) is that way since libstorage-ng uses the label reported by blkid.