Bug 497246 - /dev/dm-N names cause problems with LVM
/dev/dm-N names cause problems with LVM
Status: CLOSED DUPLICATE of bug 475773
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-22 19:23 EDT by Gerry Reno
Modified: 2009-04-30 19:34 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-23 04:04:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gerry Reno 2009-04-22 19:23:41 EDT
Description of problem:
Jonathan Underwood wrote:
> 2009/4/22 Gerry Reno <greno@verizon.net>:
>> 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
>>> 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?
>>> Regards,
>>> Gerry
>> 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:
> https://bugzilla.redhat.com/show_bug.cgi?id=475773
> 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
> clue.
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):

How reproducible:
It just happens.

Steps to Reproduce:
1. Install F10
2. wait some time
Actual results:
devices get changed from normal /dev/mapper/VolGroup00-LogVol00
to things like /dev/dm-3

Expected results:
devices do not change

Additional info:
Comment 1 Alasdair Kergon 2009-04-22 19:56:07 EDT
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.
Comment 2 Gerry Reno 2009-04-22 23:38:55 EDT
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.
Comment 3 Milan Broz 2009-04-23 04:04:06 EDT
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 ***
Comment 4 Gerry Reno 2009-04-23 12:49:28 EDT
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.
Comment 5 Milan Broz 2009-04-24 02:53:52 EDT
No, it is not.

Please read comment https://bugzilla.redhat.com/show_bug.cgi?id=497259#c3
Comment 6 Milan Broz 2009-04-24 04:07:55 EDT
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.
Comment 7 Gerry Reno 2009-04-24 11:22:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.