Bug 497246

Summary:	/dev/dm-N names cause problems with LVM
Product:	[Fedora] Fedora	Reporter:	Gerry Reno <greno>
Component:	kernel	Assignee:	LVM and device-mapper development team <lvm-team>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	low
Version:	10	CC:	agk, bmarzins, bmr, dwysocha, heinzm, itamar, kernel-maint, lvm-team, mbroz, msnitzer, prockai, quintela, zing
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-23 08:04:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gerry Reno 2009-04-22 23:23:41 UTC

Description of problem:
Jonathan Underwood wrote:
> 2009/4/22 Gerry Reno <greno>:
>  
>> 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
3. 
  
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 23:56:07 UTC

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-23 03:38:55 UTC

After one of these devices gets renamed somehow we have problems with our tools and things look like this:

/etc/fstab:
UUID is used

df:
/dev/dm-N name is used

mount:
/dev/dm-N name is used


blkid:
both /dev/mapper/VolGroup02-LogVol00 and /dev/dm-2 have the same UUID.

Comment 3 Milan Broz 2009-04-23 08:04:06 UTC

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 16:49:28 UTC

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 06:53:52 UTC

No, it is not.

Please read comment https://bugzilla.redhat.com/show_bug.cgi?id=497259#c3

Comment 6 Milan Broz 2009-04-24 08:07:55 UTC

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 15:22:00 UTC

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.