Red Hat Bugzilla – Bug 497246
/dev/dm-N names cause problems with LVM
Last modified: 2009-04-30 19:34:16 EDT
Description of problem:
Jonathan Underwood wrote:
> 2009/4/22 Gerry Reno <email@example.com>:
>> Gerry Reno wrote:
>>> We just upgraded a number of machines to F10 and after a few weeks I've
>>> noticed something wrong with lvm. Some of our inhouse scripts are breaking
>>> that deal with lvm. When I look at /etc/fstab and mount I see entries what
>>> used to look like:
>>> /dev/VolGroup00/LogVol01 / ext3 defaults 1
>>> getting changed to this:
>>> /dev/dm-3 / ext3 defaults 1 1
>>> Where does this '/dev/dm-3' device come from? I don't find it referenced
>>> in any of the lvm tool outputs. Whatever caused this change to happen
>>> please revert this back to just listing lv's in normal lvm parlance please.
>>> These mysterious changes are breaking things and are a complete nuisance.
>>> How do we go about undoing these changes and how do we prevent this from
>>> happening again?
>> No one responded to this inquiry and these mysterious changes continue to
>> happen. How can we prevent this from happening?
> Not sure what would cause that. Perhaps related to this bug:
> Can you look back through /var/log/yum.log to work out which set of
> package updates may have triggered the problem - that might provide a
Yes, that bug shows something similar but affecting mkinitrd. These machines were upgraded from F9 and then began having these mysterious changes occur with these /dev/dm-N entries. These devices bear no resemblence to any mdraid devices or LVM devices and our scripts completely croak with these devices. Why are perfectly good devices being renamed to absolutely useless names? All I want to know is how to stop whatever it is that is causing this.
Version-Release number of selected component (if applicable):
It just happens.
Steps to Reproduce:
1. Install F10
2. wait some time
devices get changed from normal /dev/mapper/VolGroup00-LogVol00
to things like /dev/dm-3
devices do not change
This needs transferring to whichever component is responsible for updating fstab.
Anyone any ideas which that is?
dm-N are internal kernel names that should not be used for anything except debugging.
After one of these devices gets renamed somehow we have problems with our tools and things look like this:
UUID is used
/dev/dm-N name is used
/dev/dm-N name is used
both /dev/mapper/VolGroup02-LogVol00 and /dev/dm-2 have the same UUID.
This is neither kernel nor lvm2 problem.
Probably mkinird one, which misinterprets device names, I am marking this as duplicate of bug #475773.
I hope that in future there no dm-X devices are visible in userspace, these are internal kernel names and are not persistent...
*** This bug has been marked as a duplicate of bug 475773 ***
Could you please explain how the issue in this bug is the same as the mkinitrd issue in the referenced bug? I see no relation between the two issues. The problems we are seeing have nothing to do with mkinitrd. This appears to be a kernel problem.
Please reopen this bug.
No, it is not.
Please read comment https://bugzilla.redhat.com/show_bug.cgi?id=497259#c3
Also please read https://bugzilla.redhat.com/show_bug.cgi?id=475773#c10 - I tried to explain what the dm-X device means.
Maybe there is still some hidden problem during update, but it is not kernel problem.
If you have reproducer (without mkinitrd / kernel update involved) please paste it here so we can reopen and reassign that bug to proper component.
Milan, can you please reopen this bug as well. What we are seeing does not appear related to the mkinitrd issue. And upon checking this problem again, the entries in /etc/fstab are all UUIDs. It is only command outputs such as 'mount' and 'df' and 'blkid' and such that show these random changes to /dev/dm-N style rather than the normal /dev/mapper/VG-LV style. And when you parse 'blkid' by UUID you get back non-unique result which by definition should not happen. UUID by definition is unique. That is the whole purpose of UUID.