Amitakhya Phukan <aphukan <at> fedoraproject.org> writes:

i have a system with fedora 7 and rhel 5 installed. recently, i changed the f7 to rawhide. now whenever i boot up, it mounts all the file systems related to rhel5 along with it and displays on the desktop. dmesg says /dev/sda1 mounted on /media/_1 and so on. I want to disable this feature. i don't know if this is anything useful ?? i even don't know if its a feature or a bug... can any one please help me out with this thing ? i understand hal is doing this (??), but why ? and even when i unmount it, the same can still be found in /media. right clicking on those partitions give me the option of mounting/unmounting them. but i don't want to let them appear in my rawhide systems totally. anyone else has this experience on rawhide??how do i disable it ??

Fedora 7 has a file called /usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi to prevent this from happening, here's its contents: <?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2"> <device> <match key="@block.storage_device:storage.hotpluggable" bool="false"> <match key="@block.storage_device:storage.removable" bool="false"> <merge key="volume.ignore" type="bool">true</merge> </match> </match> </device> </deviceinfo>

If that file is no longer there in Fedora 8, try adding it and see if that helps.

Kevin Kofler

On Thu, 2007-11-01 at 14:41 -0400, David Zeuthen wrote:

On Thu, 2007-11-01 at 12:28 +0530, Amitakhya Phukan wrote:

...

hi all!

i have a system with fedora 7 and rhel 5 installed. recently, i changed the f7 to rawhide. now whenever i boot up, it mounts all the file systems related to rhel5 along with it and displays on the desktop.

Rawhide only mounts fixed drives only when you login and only if you put in the root password and don't unclick the "Remember authorization" check box. Like this

http://people.freedesktop.org/~david/pk-gnome-mount.png

so it's most likely your own doing. There's no good UI in Rawhide/F8 for doing it except 'polkit-grant --delete <username>' as the super user.

^^^^^

s/doing/undoing/

David

On Thu, 2007-11-01 at 11:22 -0800, Jeff Spaleta wrote:

On 11/1/07, David Zeuthen david@fubar.dk wrote:

...

http://people.freedesktop.org/~david/polkit-gnome-authorizations.png

but the UI is likely to change.

Hope this helps.

Is per device policy granting in the works? So that certain disks are mountable but others aren't on a user by user basis?

See the last two paragraphs of

http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html

Basically the way it works right now is that Mechanisms split actions depending on type. Specifically for hal there's a "fixed" and "removable" split. For NM there will be "can-dial-to-trusted-number" and "can-dial-to-untrusted-number"; then the act of making something a trusted number is some other privileged operation (e.g. trusted numbers are the ones listed in a file in /etc, whatever, I don't know).

FWIW, we might add functionality later (the API is extensible) such that PolicyKit can answer questions like

"Is $PROCESS authorized to do $ACTION on $OBJECT on behalf of the user"

(now it's "Is $PROCESS authorized to do $ACTION on behalf of the user")

but right now this isn't there - mainly because there's a ton of problems in how to sanely describe an object (/dev/sda? /dev/disk/by-label ? phonenumber? etc.) and also how to build sane UI around this. Hope this helps.

-jef"Idle thought: How well does policy granting work with sabayon?"spaleta

Someone just needs to do it. It's more interesting, however, to consider PolicyKit together with http://freeipa.org/page/Main_Page . As a matter of fact, I'm already working with the FreeIPA guys on this.

David

On Fri, 2007-11-02 at 13:56 +1100, Rodd Clarkson wrote:

I've had a collection of mounts on my HD that I hadn't seen show up in f7, but were showing in rawhide in the disk mounter applet.

The mounts included:

'/' (I'm using '/1' for this install),

Stems from another OS on your hard disk.

'/var' (which should be '/var/www' anyway, and was already mounted as /var/www in my filesystem),

I bet the label of the file system is /var - that's what we display.

'/mnt/vmware' (which was mounted and already a part of my filesystem), and

'/boot' (this install of rawhide has '/boot' as part of '/1')

Again, from another OS.

and aren't the sort of thing I would have thought should have been showing up as available.

Why not? These are partitions on your hard disk. We simply just show them as of F8. Now, you can complain that the text used in the UI for these are misleading and I have to agree. We just take it from the label of the file system at this point [1]. So go complain to the people who chose the labels on your behalf. [2]

(Oh, and we also hide mounts for mount points at well-known locations, e.g. FHS2.3 and some oddities like /var/log/audit and /var/tmp.)

So to fix this, either relabel these file systems (man e2label) but please be careful to update the /etc/fstab files of the OS's using them since Fedora defaults to LABEL=. Eventually we'll get the "rename file system" from the UI going and this should be a lot easier.

David

[1] : We could be more creative and try to guess what the file system is used for; e.g. look for /etc/fedora-release, /etc/debian_release and so forth (including trying to guess if it's Windows XP, Mac OS X or whatever). So instead of showing "/" we could show "Fedora Core 7 (Moonshine)". That approach has it's ups and downs (guess is dangerous) thus why it's not implemented at this point.

[2] : This is a rant to the Anaconda team. It is beyond me why you guys decided to use LABEL= when UUID= is available for ext2/ext3 like since forever. Another complaint is the name chosen for the file systems; instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I know this screws people on updates but at least these people could rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or Anaconda could prompt the user. Thanks for looking into this.

David Zeuthen wrote:

[1] : We could be more creative and try to guess what the file system is used for; e.g. look for /etc/fedora-release, /etc/debian_release and so forth (including trying to guess if it's Windows XP, Mac OS X or whatever). So instead of showing "/" we could show "Fedora Core 7 (Moonshine)". That approach has it's ups and downs (guess is dangerous) thus why it's not implemented at this point.

How about giving a hint as to which _physical_ disk it is? Imagine you had a couple of scsi controllers each with a bunch of disks, plus some sata and USB volumes and you add one (which might currently have labels that match other drives) and want to format it. Which one is it? Or a drive in the system fails and isn't detected. How do you find which one it was?

[2] : This is a rant to the Anaconda team. It is beyond me why you guys decided to use LABEL= when UUID= is available for ext2/ext3 like since forever. Another complaint is the name chosen for the file systems; instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I know this screws people on updates but at least these people could rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or Anaconda could prompt the user. Thanks for looking into this.

How do you change the UUID's on md arrays? I often clone machines by separating RAID1 drives and letting them sync to new partners. If those separated drives ever find themselves back in the same machine, I wouldn't want them to rebuild automatically.

On Fri, 2007-11-02 at 15:18 -0400, David Zeuthen wrote:

On Fri, 2007-11-02 at 14:16 -0500, Les Mikesell wrote:

...

David Zeuthen wrote:

...

[1] : We could be more creative and try to guess what the file system is used for; e.g. look for /etc/fedora-release, /etc/debian_release and so forth (including trying to guess if it's Windows XP, Mac OS X or whatever). So instead of showing "/" we could show "Fedora Core 7 (Moonshine)". That approach has it's ups and downs (guess is dangerous) thus why it's not implemented at this point.

How about giving a hint as to which _physical_ disk it is? Imagine you had a couple of scsi controllers each with a bunch of disks, plus some sata and USB volumes and you add one (which might currently have labels that match other drives) and want to format it. Which one is it? Or a drive in the system fails and isn't detected. How do you find which one it was?

You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable.. Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit most of this before F9 as part of the gio/gvfs hacking. Stay tuned!

Also, just wanted to add, this discussion is mostly about what we use as names _on the desktop_. Still, your request is valid; if we have a bunch of similarly named drives then, sure, we should add the device name or other unique identifier.

However, things like formatting drives, partitioning, setting up LVM and RAID are most likely going to happen from a dedicated UI that will display more relevant stuff. I was kinda working on this a while back; here are some screenshots

http://people.freedesktop.org/~david/gnome-disk-utility.png http://people.freedesktop.org/~david/hal-md-normal.png http://people.freedesktop.org/~david/hal-md-degraded.png http://people.freedesktop.org/~david/hal-md-recover.png

but then other things became important. Hopefully for F10 we can have something like this... But now we're drifting off-topic :-)

David

On Fri, 2007-11-02 at 14:47 -0500, Les Mikesell wrote:

David Zeuthen wrote:

...

...

How about giving a hint as to which _physical_ disk it is? Imagine you had a couple of scsi controllers each with a bunch of disks, plus some sata and USB volumes and you add one (which might currently have labels that match other drives) and want to format it. Which one is it? Or a drive in the system fails and isn't detected. How do you find which one it was?

You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..

No - sdb1 tells me what order the OS detected it it. It says nothing about the physical connection or even which controller is involved. Does anyone actually use this system with a large number of disks that sometimes need attention? If the drive that was sdb yesterday fails in a way that keeps it from being detected, sdb will mean something else after a reboot.

Of course. That's why we show the LABEL right now. We could show the UUID but that's fugly. Btw, have you tried installing the RPM gnome-mount-nautilus-properties, right clicking the icon and choose Properties?

http://people.freedesktop.org/~david/gm-n-p-1.png http://people.freedesktop.org/~david/gm-n-p-2.png

This UI needs to be reworked to work better for enterprise use cases but basically does the job of properly identifying the drive...

Same general rant about not being able to tell/control what is really going on. I don't like the system to guess, especially when I know the answer will likely be wrong.

No one is doing any guessing here; we just display the LABEL of the file system. If you happen to have useless and/or multiple labels you get to keep them :-)

Please keep in mind this discussion is about what to show on the desktop. Which means that it needs to work for a lot of people and displaying scary stuff like UUID, device files is, generally, not going to work I think. At least not in GNOME. Hence, we need a dedicated UI for this - like gnome-disk-utility that I pointed you to in the other mail. Someone just needs to finish it so it's ready for Fedora.

...

I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if applicable; e.g. some FS's don't have UUID); and b) use some sane labels by default. The user is still free to edit /etc/fstab to use LABEL= instead of UUID= and/or relabel his drives or do whatever he wants.

And similarly, I'd like a way to peg these to physical controller/cable/drive selects because the UUIDs and labels are all going to be the same on disks that I've cloned with DD or letting RAID1's rebuild. I know you can't on USB, but about everything else has a controller/target/LUN concept to identify it.

Sure, that's something gnome-disk-utility should do. But it needs work until it's ready.

David

David Zeuthen wrote:

Rawhide only mounts fixed drives only when you login and only if you put in the root password and don't unclick the "Remember authorization" check box. Like this

http://people.freedesktop.org/~david/pk-gnome-mount.png

so it's most likely your own doing. There's no good UI in Rawhide/F8 for doing it except 'polkit-grant --delete <username>' as the super user. For F9 there will be a GNOME UI for managing these authorizations as well as the defaults; work-in-progress looks like this

http://people.freedesktop.org/~david/polkit-gnome-authorizations.png

but the UI is likely to change.

Hope this helps.

  David

hi david,

sorry for the late feedback.. i was out of office for sometime and hence didn't access my mails.

Rawhide only mounts fixed drives only when you login and only if you put in the root password and don't unclick the "Remember authorization" check box. Like this

http://people.freedesktop.org/~david/pk-gnome-mount.png

so it's most likely your own doing.

no it was not my doing.. what i did was i pointed my repositories to a local rawhide sync tree and then i did a yum -y update. i never have seen the screen you have mentioned in the above URL. Moreover, I have never logged in as root (well, except for su - )and I clearly have not used the "Keep/Forget authorisation" thing since Fedora 1.I just wanted to know what is doing this thing, and if it is a feature of rawhide *only*, I don't have any problems..I can wait for the stable release of F8..

btw, that again makes me think...what feature is enabled/disabled in rawhide and stable release and why ??

just some thoughts..

regards, amit.

On Thu, Nov 1, 2007 at 9:22 PM, Jeff Spaleta jspaleta@gmail.com wrote:

On 11/1/07, David Zeuthen david@fubar.dk wrote:

...

http://people.freedesktop.org/~david/polkit-gnome-authorizations.png

but the UI is likely to change.

Hope this helps.

Is per device policy granting in the works? So that certain disks are mountable but others aren't on a user by user basis?

-jef"Idle thought: How well does policy granting work with sabayon?"spaleta

-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

Hi David, I saw this a bit older thread and looked at PolicyKit manual and if I'm not mistaken now you have the ability to make a more granual per-device policies, right?

Have the talks with anaconda team continued? What is the verdict? UUID or back to labels?

Cheers, Valent.