This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 495170 - no DM_* env variables set with default udev rules
no DM_* env variables set with default udev rules
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
NEEDSRETESTING
: Reopened
Depends On:
Blocks: F12Target
  Show dependency treegraph
 
Reported: 2009-04-09 22:25 EDT by David Zeuthen
Modified: 2013-03-05 22:58 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-28 07:54:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
logs requested by davidz (20.00 KB, application/x-tar)
2009-06-03 05:48 EDT, Tomeu Vizoso
no flags Details

  None (edit)
Description David Zeuthen 2009-04-09 22:25:59 EDT
With Fedora 11 we have switched to a new subsystem for disk enumeration and handling. One unintended side effect is that the ext4 read-only filesystem the livecd is based on, is visible (and mountable) in the desktop shell.

This happens, I believe, because the livecd boot scripts sets up the read-only device node /dev/dm-1 as the readable part of the /dev/mapper/live-rw writeable device.

As such /dev/dm-1 itself isn't mounted and since it contains a mountable file system we present it to the user like any other device with a mountable file system.

One way to work around this is to mount /dev/dm-1 somewhere in /mnt during booting. I'm not sure there's a better way to deal with this right now.

For reference note that

 /dev/dm-0 == /dev/mapper/live-rw
 /dev/dm-1 == /dev/mapper/live-osimg-min

See bug 495033 comment 9 for more details.
Comment 1 David Zeuthen 2009-04-12 13:12:10 EDT
I looked a bit more at this today so see if maybe DeviceKit-disks or the gvfs bits were to blame for this. This is what I found.

First, this is where the /dev/mapper/live-osimg-min device node is set up

http://git.fedoraproject.org/git/?p=mkinitrd;a=blob;f=mkliveinitrd;h=6054b5b67e92c62c89a9f6e41dd0a792ed3a6733;hb=HEAD#l797

I believe this device node is created for solely for the convenience of anaconda (which is fine I think, makes it much easier to write the installer instead of setting this up itself) - is that about right?

Note that we didn't show device-mapper devices (except for dm-crypt ones unlocked by HAL itself) prior to switching to DeviceKit-disks simply because HAL ignored such device nodes. So clever tricks like /dev/mapper/live-osimg-min wasn't a problem until now ;-)

However, now that we show don't ignore such devices (which is the right thing to do, it's a user mountable file system after all and gods know that we use device-mapper in other ways too (LVM, dmraid, etc.) so we generally don't want to ignore anything) we need to hide it from the desktop shell as it is confusing to users.

The best way to do hide this device from the UI is to mount it in a place where we know the UI tools will ignore it. E.g. /mnt/live-osimg-min or something. Since it's a read-only mapping this won't really change anything.
Comment 2 Jeremy Katz 2009-04-14 13:23:27 EDT
(In reply to comment #1)
> First, this is where the /dev/mapper/live-osimg-min device node is set up
[snip]
> I believe this device node is created for solely for the convenience of
> anaconda (which is fine I think, makes it much easier to write the installer
> instead of setting this up itself) - is that about right?

Yep.  It's a little more than just convenience, though, as it might well not be possible to create the minimal snapshot when anaconda runs given the way the whole stack mounts with some pieces hidden.  Sadly, this is the sort of problem I knew would eventually creep into existence when people were pushing for the "copy the minimal fs instead of the full thing" :/

> Note that we didn't show device-mapper devices (except for dm-crypt ones
> unlocked by HAL itself) prior to switching to DeviceKit-disks simply because
> HAL ignored such device nodes. So clever tricks like /dev/mapper/live-osimg-min
> wasn't a problem until now ;-)
> 
> However, now that we show don't ignore such devices (which is the right thing
> to do, it's a user mountable file system after all and gods know that we use
> device-mapper in other ways too (LVM, dmraid, etc.) so we generally don't want
> to ignore anything) we need to hide it from the desktop shell as it is
> confusing to users.
> 
> The best way to do hide this device from the UI is to mount it in a place where
> we know the UI tools will ignore it. E.g. /mnt/live-osimg-min or something.
> Since it's a read-only mapping this won't really change anything.  

While it won't change anything, it feels a little kludgey and could end up meaning that we tickle new (mis)behavior of the kernel if any reads/writes occur there.  It's definitely not going to be something which is allowed when we can eventually use the union mount stuff that Val is working on.  So something a little bit more explicit than "it's mounted" to give a hint to dk-disks would get a slight preference for me.  Especially as it's something I can see people wanting for other cases.

That said, for now, I guess we can mount it somewhere, but how are you checking for it being mounted?  eg, if I mount it in the initramfs somewhere that then is completely inaccessible after the pivot, is that good enough?  Or do we have to have it mounted and accessible?  Also do you check for the "nice" name (live-osimg-min) or the actual dm name?  Or compare device major/minor?
Comment 3 David Zeuthen 2009-04-14 14:28:47 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > First, this is where the /dev/mapper/live-osimg-min device node is set up
> [snip]
> > I believe this device node is created for solely for the convenience of
> > anaconda (which is fine I think, makes it much easier to write the installer
> > instead of setting this up itself) - is that about right?
> 
> Yep.  It's a little more than just convenience, though, as it might well not be
> possible to create the minimal snapshot when anaconda runs given the way the
> whole stack mounts with some pieces hidden.  Sadly, this is the sort of problem
> I knew would eventually creep into existence when people were pushing for the
> "copy the minimal fs instead of the full thing" :/
> 
> > Note that we didn't show device-mapper devices (except for dm-crypt ones
> > unlocked by HAL itself) prior to switching to DeviceKit-disks simply because
> > HAL ignored such device nodes. So clever tricks like /dev/mapper/live-osimg-min
> > wasn't a problem until now ;-)
> > 
> > However, now that we show don't ignore such devices (which is the right thing
> > to do, it's a user mountable file system after all and gods know that we use
> > device-mapper in other ways too (LVM, dmraid, etc.) so we generally don't want
> > to ignore anything) we need to hide it from the desktop shell as it is
> > confusing to users.
> > 
> > The best way to do hide this device from the UI is to mount it in a place where
> > we know the UI tools will ignore it. E.g. /mnt/live-osimg-min or something.
> > Since it's a read-only mapping this won't really change anything.  
> 
> While it won't change anything, it feels a little kludgey and could end up
> meaning that we tickle new (mis)behavior of the kernel if any reads/writes
> occur there.  It's definitely not going to be something which is allowed when
> we can eventually use the union mount stuff that Val is working on.  So
> something a little bit more explicit than "it's mounted" to give a hint to
> dk-disks would get a slight preference for me.  Especially as it's something I
> can see people wanting for other cases.

The device is created read-only... so I'd be surprised if mounting it would change anything.

> That said, for now, I guess we can mount it somewhere, but how are you checking
> for it being mounted?  eg, if I mount it in the initramfs somewhere that then
> is completely inaccessible after the pivot, is that good enough?  Or do we have
> to have it mounted and accessible?  Also do you check for the "nice" name
> (live-osimg-min) or the actual dm name?  Or compare device major/minor?  

To check if something is mounted I look at /proc/self/mountinfo and compare only on major:minor. I also discard all entries for which fourth entry is not "/" so not sure if it's going to work in the initramfs, haven't looked at the /proc/self/mountinfo code for a while. It might work... Definitely worth trying.

Wrt. to Val's union mount stuff (which is good stuff!) I guess we're going to have to find a way to properly support that when it lands; we'd probably need changes to apps (such as devkit-disks and the stack above it) relying on things like /proc/self/mountinfo ... much the same way we need changes to properly deal with multi-disk file systems such as btrfs, cf. bug 495152 comment 31. Or maybe not, we'll see ;-)

Thanks for looking into this.
Comment 4 Jeremy Katz 2009-04-14 14:57:56 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > First, this is where the /dev/mapper/live-osimg-min device node is set up
> > [snip]
> > > I believe this device node is created for solely for the convenience of
> > > anaconda (which is fine I think, makes it much easier to write the installer
> > > instead of setting this up itself) - is that about right?
> > 
> > Yep.  It's a little more than just convenience, though, as it might well not be
> > possible to create the minimal snapshot when anaconda runs given the way the
> > whole stack mounts with some pieces hidden.  Sadly, this is the sort of problem
> > I knew would eventually creep into existence when people were pushing for the
> > "copy the minimal fs instead of the full thing" :/
> > 
> > > Note that we didn't show device-mapper devices (except for dm-crypt ones
> > > unlocked by HAL itself) prior to switching to DeviceKit-disks simply because
> > > HAL ignored such device nodes. So clever tricks like /dev/mapper/live-osimg-min
> > > wasn't a problem until now ;-)
> > > 
> > > However, now that we show don't ignore such devices (which is the right thing
> > > to do, it's a user mountable file system after all and gods know that we use
> > > device-mapper in other ways too (LVM, dmraid, etc.) so we generally don't want
> > > to ignore anything) we need to hide it from the desktop shell as it is
> > > confusing to users.
> > > 
> > > The best way to do hide this device from the UI is to mount it in a place where
> > > we know the UI tools will ignore it. E.g. /mnt/live-osimg-min or something.
> > > Since it's a read-only mapping this won't really change anything.  
> > 
> > While it won't change anything, it feels a little kludgey and could end up
> > meaning that we tickle new (mis)behavior of the kernel if any reads/writes
> > occur there.  It's definitely not going to be something which is allowed when
> > we can eventually use the union mount stuff that Val is working on.  So
> > something a little bit more explicit than "it's mounted" to give a hint to
> > dk-disks would get a slight preference for me.  Especially as it's something I
> > can see people wanting for other cases.
> 
> The device is created read-only... so I'd be surprised if mounting it would
> change anything.

The kernel regularly finds new ways to surprise me :-)

> > That said, for now, I guess we can mount it somewhere, but how are you checking
> > for it being mounted?  eg, if I mount it in the initramfs somewhere that then
> > is completely inaccessible after the pivot, is that good enough?  Or do we have
> > to have it mounted and accessible?  Also do you check for the "nice" name
> > (live-osimg-min) or the actual dm name?  Or compare device major/minor?  
> 
> To check if something is mounted I look at /proc/self/mountinfo and compare
> only on major:minor. I also discard all entries for which fourth entry is not
> "/" so not sure if it's going to work in the initramfs, haven't looked at the
> /proc/self/mountinfo code for a while. It might work... Definitely worth
> trying.

So /proc/self/mountinfo looks like it only includes things which are mounted that are visible to you.  eg, if I chroot, then I only see things mounted in the chroot and nothing outside of it.  So that's certainly not going to work if I do the mount somewhere before we pivot to the real root.  

I really don't want to have to be littering the fs where users are going to be able to see and potentially get confused about things so some other method of saying "hey, this isn't a device to care about" would really be useful.
Comment 5 David Zeuthen 2009-04-15 11:33:53 EDT
Not sure mounting it in /mnt/stuff is going to litter the filesystem and not sure it's a huge inconvenience to users. 

Anyway, we probably need a mechanism to hide unwanted devices _anyway_ (things like recovery partitions) so I've added a way to do that .. it's now possible to do by setting a udev property DKD_PRESENTATION_HIDE on the device. So you'd need to add a udev rule that sets this property e.g. something like (untested)

 ACTION=="add|change", KERNEL=="dm-1", ENV{DKD_PRESENTATION_HIDE}="1"

where you might want to tweak KERNEL=="dm-1" to something that matches on the dm/name attribute or something else. You can check with devkit-disks(1) that the rule is right, something like

 $ devkit-disks --show-info /dev/dm-1 |grep -i hide
   presentation hide:       0

I'll follow up when this is in Rawhide and F11. It involves updates to DeviceKit-disks, gnome-disk-utility and gvfs (yea, all the layers in the stack since it's a hint to the ui bits).
Comment 6 David Zeuthen 2009-04-16 11:20:00 EDT
This is now in 

 DeviceKit-disks-004-0.9.20090415git.fc11
 gnome-disk-utility-0.3-0.5.20090415git.fc11
 gvfs-1.2.2-3.fc11

Let me know how it works out.
Comment 7 Jeremy Katz 2009-04-16 16:12:06 EDT
Looks good in a quick test.  mkinitrd-6.0.82 building now
Comment 8 Jesse Keating 2009-05-11 13:30:28 EDT
This just needs re-testing I believe.
Comment 9 Jesse Keating 2009-05-12 17:37:07 EDT
I don't see those items any more, closing.
Comment 10 Tomeu Vizoso 2009-06-02 05:35:41 EDT
Just updated to a later build and I'm seeing this again, /dev/dm-2 is mounted on /media/F10-PR-i686-Live

And gvfs/gdu is listing this again as an user-visible mount.
Comment 11 David Zeuthen 2009-06-02 10:53:55 EDT
(In reply to comment #10)
> Just updated to a later build and I'm seeing this again, /dev/dm-2 is mounted
> on /media/F10-PR-i686-Live
> 
> And gvfs/gdu is listing this again as an user-visible mount.  

Please include the information requested here

 http://www.freedesktop.org/wiki/Software/DeviceKit-disks
Comment 12 Jeremy Katz 2009-06-02 15:20:25 EDT
Hmmm, the udev rule is still there but it doesn't look like it's being called.  It certainly was before, though.

Harald -- has anything of note changed in udev?
Comment 13 Jeremy Katz 2009-06-02 15:25:40 EDT
Also, while a little bit ugly, this doesn't really meet the criteria for a blocker (and never did) as it doesn't lead to data corruption, etc.  And in the scheme of UI quirks, it's not even that high on the list.

So moving to target (and still poking at it)
Comment 14 Harald Hoyer 2009-06-03 02:37:49 EDT
F-11 udev hasn't changed for quite a while now.

$ rpm -q udev --changelog|head
* Fri Apr 24 2009 Harald Hoyer <harald@redhat.com> 141-3

Because LVM creates /dev/mapper/* and /dev/VGNAME/LVNAME itsself, udev does not know about them. /dev/dm-* has to be created, as the mantra is to create the devices with the kernel name and just create symlinks, which are more suitable.
Comment 15 Tomeu Vizoso 2009-06-03 05:48:48 EDT
Created attachment 346370 [details]
logs requested by davidz
Comment 16 Bug Zapper 2009-06-09 09:35:34 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Jeremy Katz 2009-07-06 16:34:50 EDT
Okay, I tracked down what's going on.  With the current udev rules, we're not getting DM_NAME in the environment with default udev rules, it's only coming from anaconda/devkit-disks rules.  

I can workaround this by either importing the info from dmsetup myself or appending this specific rule to the devkit-disks rules file, but that feels a bit ugly.  The right fix is to get udev and device-mapper not working at odds.  Which then also gives the added advantage of being able to drop extra rules getting this information for things like anaconda, devkit-disks, etc.
Comment 18 David Zeuthen 2009-07-06 17:27:14 EDT
(In reply to comment #17)
> Okay, I tracked down what's going on.  With the current udev rules, we're not
> getting DM_NAME in the environment with default udev rules, it's only coming
> from anaconda/devkit-disks rules.  
> 
> I can workaround this by either importing the info from dmsetup myself or
> appending this specific rule to the devkit-disks rules file, but that feels a
> bit ugly.  The right fix is to get udev and device-mapper not working at odds. 
> Which then also gives the added advantage of being able to drop extra rules
> getting this information for things like anaconda, devkit-disks, etc.  

Completely agree, as a general sentiment neither anaconda nor devkit-disks should avoid polluting any namespace that isn't their own (and devkit-disks don't do that much anymore, the few things it needs from device-mapper is prefixed with DKD_ (via it's own prober) and can be obtained with little work - things it needs from MD doesn't involve opening all block devices and with recent MD/udev we don't do extra work since we check if MD_* stuff is already set).

So, yeah, I think we agree. Ideally anaconda and devkit-disks (and any other high-level tool like that for that matter) have no business running commands that should be run by rules from the appropriate packages. 

E.g. where we want to be is that the device-mapper/LVM packages supplies it's own udev rules, ditto for the mdadm package.

Btw, /lib/udev/rules.d/70-anaconda.rules is scary reading, there's this snippet

 # probe metadata of LVM2 physical volumes
 ENV{ID_FS_TYPE}=="LVM2_member", IMPORT{program}="$env{ANACBIN}/lvm pvs \
    --units k --nosuffix --nameprefixes --rows --unquoted --noheadings \
-opv_name,pv_uuid,pv_size,vg_name,vg_uuid,pv_pe_count,pv_pe_alloc_count,pe_start $tempnode"

Do you realize just how expensive this operation is? With the way the LVM tools currently work, each invocation is going to open all block devices. This is a sure way to kill big boxes with many LVM PV's. Also, It's double-plus bad because anaconda tends to remain installed, at least in the live cd case.

I've asked the LVM guys to fix their tools for a some time now (e.g. stop opening all block devices (by using things like libudev to read metadata), supply udev rules that sets attributes that anaconda/devkit-disks can rely on) but thus far they haven't done anything for PVs, there's only some work for the mapped device case (which incidentally is what you need for the live cd case, e.g. DM_NAME). It would be good if the anaconda team can apply some pressure here as well.

Actually I think this bug should be reassigned from udev to the device-mapper/LVM package since the device-mapper is the package that should supply udev rules...
Comment 19 Harald Hoyer 2009-07-13 04:55:32 EDT
(In reply to comment #18)
> Actually I think this bug should be reassigned from udev to the
> device-mapper/LVM package since the device-mapper is the package that should
> supply udev rules...  

agreed
Comment 20 Bug Zapper 2010-04-27 09:36:20 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Alasdair Kergon 2010-04-27 10:34:26 EDT
Peter, please check whether or not this is all now covered by existing work.
Comment 22 Peter Rajnoha 2010-04-28 07:54:18 EDT
We've added udev support already and as for the udev variables, we provide them as well (including above mentioned DM_NAME). Users can find all accessible variables listed in comments in the udev rules directly.

The part of this bug report that mentioned the expensiveness of LVM2 operations while trying to gather all information requested - this should be one of the goals of planned persistent cache support (see newly opened bug #586791).

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