Red Hat Bugzilla – Bug 199697
Doesn't react well to missing paths
Last modified: 2015-01-07 19:13:38 EST
1. Setup a machine with multipath (you don't really need to, the /etc/blkid.tab
needs to reflect that though)
<device DEVNO="0x0802" TIME="1151916502" LABEL="/test"
<device DEVNO="0x0842" TIME="1151916502" LABEL="/test"
Both paths lead to /test
2. Remove a path (/test is on /dev/sda1 and /dev/sde1 for example, but is still
present in the blkid.tab and /etc/fstab)
3. Reboot the machine, and look at fsck stop dead in its tracks, as it cannot
find /test (again, testcase just below)
Here's a simple testcase that replicates what fsck does right now:
int main (int argc, char **argv)
name = blkid_get_devname(blkid, "LABEL=/test", 0);
printf ("name: %s\n", name);
As the path has been removed, and neither block devices exist anymore (both
/dev/sda2 and /dev/sde2 are gone), fsck will try to access those, and stop saying:
[/sbin/fsck.ext3 (1) -- /test] fsck.ext3 -a LABEL=/test
fsck.ext3: Unable to resolve 'LABEL=/test'
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Give root password for maintenance
It would be good if fsck could try harder to find a valid device path for that
Labels should be unique on your system. If you are using a label more than once,
then it is required to use the first entry in the list to be consistent. I think
it is not a good idea if blkid takes the first in the list which is physically
available, because this could result in a partition switch, which would be very
bad, e.g. if you switch /tmp with /home, because /tmp is not there and both
partitions have the same label.
I could only say: DO not use labels with multipath or software-raid.
> I could only say: DO not use labels with multipath or software-raid.
Anaconda will take labels, if a filesystem is on the real devices.
Also, the concept of using label is handling filesystem well even if the
physical device name is changed, right ?
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
For lack of a better resolution type, NOTABUGging this one based on the IT
closing; also, from my understanding, we have a by-label entry in fstab for
which there is no device containing that label, and fsck stops. This looks to
me like simply a misconfiguration....