Created attachment 339012 [details] output of fdisk and blkid Description of problem: When looking at "Computer:///" block devices that are parts of dmraid sets are shown. dmraid block devices are also shown - as in complete raid sets. They are also shown under the palimpsest disk utility where they should not. Version-Release number of selected component (if applicable): Rawhide 10/04/09 How reproducible: Always there Steps to Reproduce: 1. Create hardware fakeraid array from 2 or more disks 2. boot system and verify raid set was initialised and rebuild properly 3. open nautilus and go to "Computer:///" Actual results: It shows block devices where it should not and even shows the complete array where it should not Expected results: not show block devices or total raid array sets and instead only show mountable partitions Additional info: My setup is as follows: * F11 Rawhide x86_64 * Core2 E6750 * Asus Striker Extreme w/ Nvidia 680i chipset and mediashield fakeraid controller * 2x 74GB raptors in FakeRAID0 * 2x 750GB Seagate's in JBOD I've attached the following screen shots and outputs to help illustrate the situation: # output of "fdisk -l" and "blkid" # screenshot of palimpsest utility # screenshot of nautilus I have been working with Hans Degoede and Joel Granados on the dmraid bug #489148 so they may be able to provide more information on the upstream changes they made to dmraid or on fakeraid sets in general.
Created attachment 339014 [details] Screenshot of Computer file browser
Created attachment 339015 [details] Screenshot of Palimpsest utility
Please attach the output of 'devkit-disks --dump' from a fully updated Rawhide system (remember to reboot after updating DeviceKit-disks). Thanks.
Comment on attachment 339012 [details] output of fdisk and blkid Wrong MIME type...
Still interested in 'devkit-disks --dump' output but from what I can tell this bug (or most of it anyway) should be fixed in gvfs-1.2.1-3.fc11... one bug fixed there is that we no longer show a drive object for drives without any recognizable filesystems (such as fakeraid devices). Please try gvfs-1.2.1-3.fc11 http://koji.fedoraproject.org/koji/buildinfo?buildID=97280
Also, with that gvfs version, please attach the output of 'gvfs-mount -li' (when logged in). Thanks.
Created attachment 339047 [details] output of fdisk and blkid
Created attachment 339048 [details] output of devkit-disks --dump
Created attachment 339050 [details] output of gvfs-mount It's still showing the same thing as my previous screen shots # downloaded x86_64 rpm's from the link posted in comment #5 # rpm -Uvh gvfs* # reboot
Comment on attachment 339047 [details] output of fdisk and blkid (In the future please pay attention to the MIME type (e.g. text/plain) so the it's possible to view the attachment in the browser. Thanks.)
(In reply to comment #9) > It's still showing the same thing as my previous screen shots By "it" you mean Palimpsest, right? According to gvfs-mount output, computer:/// shouldn't show any block devices anymore...
both palimpsest and nautilus. does nautilus keep a cache like blkid? are you on irc?
Created attachment 339052 [details] output of fdisk and blkid - again... sorry for that, bugzilla wasn't auto-detecting properly, either that or .out is a known extension for another data type. this time i've manually selected plain text so we should be ok... why is it that, opposed to Fedora <10, some mapper devices are being referred to as /dev/dm-X and others under the more commonly known /dev/mapper/foo? personally i prefer their /dev/mapper alias because it's far more intuitive to use and such
(In reply to comment #9) > Created an attachment (id=339050) [details] > output of gvfs-mount Did you capture this output from within the desktop session? It looks like either gvfs is buggy or you captured via ssh or one of the VT sessions.
(In reply to comment #12) > both palimpsest and nautilus. does nautilus keep a cache like blkid? No, Nautilus relies on the information in the udev database; no caches are ever used. > are you on irc? Not tonight.
Created attachment 339054 [details] output of gvfs-mount run as user crap! I was running it as root from the terminal... yeah, there's a bit more output now... :|
OK, that looks better. Let's review /dev/sr0 : we should show this because it represents the optical drive and disc /dev/dm-4: this is shown because it's a mountable filesystem. If you gave the filesystem a label, we'd show that instead of "20G Filesystem" /dev/dm-2: again, this is a mountable filesystem so we show it.. if you want a better name than "120G Filesystem" you can set a filesystem label on the device /dev/dm-1, /dev/dm-7: these are not shown because these are mounted at /boot resp. /storage and we hide things mounted outside /media and $HOME /dev/dm-3, /dev/dm-5, /dev/dm-8: we don't show swap partitions in the file manager /dev/dm-0, /dev/dm-6, /dev/sda, /dev/sdc: we shouldn't show these... I think I know what's wrong here === Conclusion: we erroneously show the devices /dev/dm-0 /dev/dm-6 /dev/sda /dev/sdc in computer:///. That needs to be fixed, I'll look into that (pretty sure I know what's wrong). When this is fixed you will only see icons for these drives /dev/sr0 (icon: cdrom, title: Fedora) /dev/dm-2 (icon: hd, title: 120G Filesystem) /dev/dm-4 (icon: hd, title: 20G Filesystem) in the file manager which is how it is supposed to work.
Btw, I wonder where the root file system is. Any chance you can paste the output of - cat /proc/self/mountinfo - cat /etc/mtab Thanks?
(In reply to comment #18) > Thanks? Eh, I meant "Thanks!", not "Thanks?". Sorry about that!
My guess is that /dev/dm-4 is the root filesystem but something fishy is preventing us from detecting that.
(In reply to comment #13) > why is it that, opposed to Fedora <10, some mapper devices are being referred > to as /dev/dm-X and others under the more commonly known /dev/mapper/foo? > personally i prefer their /dev/mapper alias because it's far more intuitive to > use and such Yeah, I agree /dev/mapper/* names would make it a lot nicer. The reason /dev/dm-X is used is that is the canonical device node name as assigned by the kernel... the kernel representation of the device is in /sys/block/dm-0 for example... this is a bit like /dev/sda is the canonical name for the first ATA/SCSI disk but the symlink /dev/disk/by-id/ata-INTEL_SSDSA2MH080G1GC_CVEM842101HD080DGN is more useful. There's also the problem that device-mapper is poorly integrated with udev (the device-mapper tools writes it's own device nodes in /dev/mapper so it's hard to integrate with) and the asynchronous uevent delivery model that the rest of the OS is using.
Created attachment 339065 [details] requested output from comment 18 I have also included: # ls -lha /dev/dm* # ls -lha /dev/mapper/ the following is just a summary of info listed in the attached file and a compilation of attachment #339052 [details] dm-2 is c:\ and is 120GB's of NTFS madness. i just ran ntfslabel and made a static on boot entry in /etc/fstab so it should be out of the equation dm-3 isn't swap, it's the LVM PV dm-4 is /, is formatted as BTRFS and is a part of my LVM which also has swap on it. To make / btrfs I did it all through anaconda 11.5.0.39 It seems that it shows sda and sdc because the block device has a readable partition table, sdb is the second of the raid0 pair and sdd is the second of a JBOD therefore have no MBR. Bearing in mind i'm using a fakeraid solution. > /dev/dm-4 (icon: hd, title: 20G Filesystem) It's root.. brw-rw----. 1 root disk 253, 4 2009-04-10 23:16 LVM-Root / brw-rw----. 1 root disk 253, 5 2009-04-10 23:16 LVM-Swap swap brw-rw----. 1 root disk 253, 0 2009-04-10 23:16 nvidia_afcjhada sda/b brw-rw----. 1 root disk 253, 1 2009-04-10 13:46 nvidia_afcjhadap1 /boot brw-rw----. 1 root disk 253, 2 2009-04-10 15:09 nvidia_afcjhadap2 C drive brw-rw----. 1 root disk 253, 3 2009-04-10 23:16 nvidia_afcjhadap3 LVM brw-rw----. 1 root disk 253, 6 2009-04-10 13:46 nvidia_bfeafffe sdc/d brw-rw----. 1 root disk 253, 7 2009-04-10 13:46 nvidia_bfeafffep1 /storage brw-rw----. 1 root disk 253, 8 2009-04-10 13:46 nvidia_bfeafffep2 swap > Eh, I meant "Thanks!", not "Thanks?". Sorry about that! lol, it's all good :)
Regarding comment #21 >There's also the problem that device-mapper is poorly integrated with udev (the >device-mapper tools writes it's own device nodes in /dev/mapper so it's hard to >integrate with) and the asynchronous uevent delivery model that the rest of the >OS is using. bug #494821 has been raised and seems to be about this.
The first line in /proc/self/mountinfo is the culprit 19 1 0:16 / / rw,relatime - btrfs /dev/root rw I think it should read 253:4 instead. Either way, I'll try to get to the gvfs bugs this weekend; the rootfs problem may be harder.
Hi, Please try the gvfs-1.2.1-5.fc11 packages http://koji.fedoraproject.org/koji/taskinfo?taskID=1291110 (you need to logout/login for changes to take effect). These packages should fix the problem with /dev/dm-0, /dev/dm-6, /dev/sda, /dev/sdc appearing in computer:///. Note that since the problem with /dev/dm-4 and /proc/self/mountinfo is still unresolved you should be seeing the following icons in computer:// - An icon for the Fedora CD (if inserted) - An icon for the NTFS volumes - An icon for the btrfs root filesystem (which shouldn't be shown) Please include the output of 'gvfs-mount -li' and a screenshot of computer:///. I'm still looking at the problem with /dev/dm-4 and /proc/self/mountinfo - maybe we can work around this by special casing '/'. What is the output of 'stat /' on your system? Thanks.
Created attachment 339205 [details] gvfs-mount -li w00t, gvfs-1.2.1-5.fc11.x86_64 worked, good stuff and thanks. I found a bit of a problem with double clicking on "20 GB Filesystem", I was prompted for root pw and typed it successfully, it mounted and i could see everything on / and for obvious reasons when I clicked the eject icon it wouldn't unmount :). but i suppose this is secondary to the real problem. [pb@x64 ~]$ stat / File: `/' Size: 184 Blocks: 8 IO Block: 4096 directory Device: 11h/17d Inode: 256 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-04-12 10:16:22.344224264 +0930 Modify: 2009-04-12 09:56:12.271588909 +0930 Change: 2009-04-12 09:56:12.271588909 +0930
Created attachment 339206 [details] Screenshot of Computer file browser - 2
(In reply to comment #26) > Created an attachment (id=339205) [details] > gvfs-mount -li > > > w00t, gvfs-1.2.1-5.fc11.x86_64 worked, good stuff and thanks. Great, thanks for testing. > I found a bit of > a problem with double clicking on "20 GB Filesystem", I was prompted for root > pw and typed it successfully, it mounted and i could see everything on / and > for obvious reasons when I clicked the eject icon it wouldn't unmount :). but > i suppose this is secondary to the real problem. Yeah, once we fix that bug "20 GB Filesystem" won't be shown in computer:///. > [pb@x64 ~]$ stat / > File: `/' > Size: 184 Blocks: 8 IO Block: 4096 directory > Device: 11h/17d Inode: 256 Links: 1 Hmm, it still says that dev_t is 0:17 which is consistent with the output of /proc/self/mountinfo... so we can't even do a workaround. Unless we rely on /etc/mtab (which is not a good idea).
regretfully the programming side of things is beyond my abilities... If gvfs handles the auto mounting of all devices like usb drives and such i have another bug for you that is storage related. I plug in my Nokia 6300 via usb and select "storage mode", blkid shows /dev/sde is of type "vfat" (not /dev/sde1 or 2), i can manually mount it and all is well but it does not automount like all other usb storage devices. do you need a separate bug lodged or is it related? Thanks for your help thus far, it's greatly appreciated :)
(In reply to comment #29) > regretfully the programming side of things is beyond my abilities... > > If gvfs handles the auto mounting of all devices like usb drives and such i > have another bug for you that is storage related. I plug in my Nokia 6300 via > usb and select "storage mode", blkid shows /dev/sde is of type "vfat" (not > /dev/sde1 or 2), i can manually mount it and all is well but it does not > automount like all other usb storage devices. do you need a separate bug > lodged or is it related? That's a separate bug, please file it against DeviceKit-disks and include the output of 'devkit-disks --monitor-detail' and 'gvfs-mount -oi' when plugging in the device. Then when plugged in, include the output of 'devkit-disks --dump' and 'gvfs-mount -li'. Thanks! > Thanks for your help thus far, it's greatly appreciated :) Thanks for testing!
The issue mentioned in comment 24 has been reported to the btrfs list http://article.gmane.org/gmane.comp.file-systems.btrfs/2851 and it looks like (but the jury is still out) that we need to add some code specific to btrfs to make things work. We should probably add a work-around till then... Btw, regarding the what Palimpsest Disk Utility shows you (cf. comment 0 and comment 2), it's supposed to look like that (modulo missing device names). Yes, it's not pretty but that's device-mapper for you. Ideally dmraid would be in the kernel and things wouldn't be this ugly but that's just not how things work today. Do note that there's an effort to make Linux MD work with fakeraid (DDF and Intel Matrix RAID for now) so maybe one day this will be less ugly.
I've added this workaround http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=abea041f6f6c63fef70a4964c13ec4415e23e626 and this is in DeviceKit-disks-004-0.7.20090412git.fc11. http://koji.fedoraproject.org/koji/taskinfo?taskID=1292589