Bug 495170

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.

(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?

(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.

(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.

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).

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.

Looks good in a quick test.  mkinitrd-6.0.82 building now

This just needs re-testing I believe.

I don't see those items any more, closing.

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.

(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

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?

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)

F-11 udev hasn't changed for quite a while now.

$ rpm -q udev --changelog|head
* Fri Apr 24 2009 Harald Hoyer <harald> 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.

Created attachment 346370 [details]
logs requested by davidz

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

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.

(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...

(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

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

Peter, please check whether or not this is all now covered by existing work.

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).