Created attachment 342118 [details] computer window The nautilus computer window is a less than optimal experience when booting the live cd right now. It shows two mysterious '2 GB' devices, it also shows my harddisk, and it shows the expected cdrom drive and filesystem entries. Both of the '2 GB' and the harddisk entries have 'Mount' menuitem, but none of them works. What I would expect to see here in this case is my actual partitions on the harddisk, to be able to mount them. Palimpsest shows them just fine, and can mount them without problems. I'll attach a few things...
Created attachment 342119 [details] mounting fails
Created attachment 342120 [details] palimpsest can do it
Created attachment 342121 [details] devkit-disks --dump
Created attachment 342122 [details] cat /proc/self/mountinfo
Created attachment 342123 [details] gvfs-mount -li
What version of gvfs is this?
Either way, it's a gvfs problem - we're not honoring :device-presentation-hide property...
gvfs-1.2.2-3.fc11 So, what problem will honoring :device-presentation-hide solve ? I assume it might make the '2 GB' entries go away. But what about showing the entries that we can actually usefully mount, ie /home etc ?
(In reply to comment #8) > gvfs-1.2.2-3.fc11 > > So, what problem will honoring :device-presentation-hide solve ? > > I assume it might make the '2 GB' entries go away. Yes. > But what about showing the > entries that we can actually usefully mount, ie /home etc ? Why do you think showing an implementation detail such as /home is useful?
> Why do you think showing an implementation detail such as /home is useful? Trying the live cd is easier if I have access to my actual data... /home is an implementation detail when it is automatically mounted at boot. It is not when it sits on my harddisk and I don't know how to get at it because the ui is not helping...
(In reply to comment #10) > > Why do you think showing an implementation detail such as /home is useful? > > Trying the live cd is easier if I have access to my actual data... /home is an > implementation detail when it is automatically mounted at boot. It is not when > it sits on my harddisk and I don't know how to get at it because the ui is not > helping... Wait, what? I thought you meant /home as mounted into the file system, not some block device that happens to have the label "/home" just because the installer team or someone else decided that label is useful (calling it "Home Directories" is more useful and avoids conceptual clusterfucks like these). Maybe if you had said "/dev/sda2" it would have helped - I still can't read minds :-) Anyway, /dev/sda2 has "presentation hide: 1" so it's probably the livecd boot scripts we should blame - any chance you can attach the udev rule from the live cd system that sets DKD_PRESENTATION_HIDE? (grep in /{etc,lib}/udev/rules.d)
50-udev-default.rules has DM_NAME=="live-osimg-min" EN{DKD_PRESENTATION_HIDE}="1" That is the only occurrence of DKD_PRESENTATION_HIDE in the livecd
(In reply to comment #12) > 50-udev-default.rules has > > DM_NAME=="live-osimg-min" EN{DKD_PRESENTATION_HIDE}="1" > > > That is the only occurrence of DKD_PRESENTATION_HIDE in the livecd Try $ udevadm info --export-db|grep HIDE
(In reply to comment #13) > (In reply to comment #12) > > 50-udev-default.rules has > > > > DM_NAME=="live-osimg-min" EN{DKD_PRESENTATION_HIDE}="1" Did you type this wrong (missing ',' and EN should be ENV)? Or are the typos in the rules? > > > > > > That is the only occurrence of DKD_PRESENTATION_HIDE in the livecd > > Try > > $ udevadm info --export-db|grep HIDE Also, please attach the output of that command (e.g. 'udevadm info --export-db')
That grep command yields a ton of E: DKD_PRESENTATION_HIDE=1 lines, not very useful. I'll attach the full dump
Created attachment 342153 [details] udevadm info --export-db
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
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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.