PDA

View Full Version : Anyone knows why mount locations changed?


DBelton
8th March 2012, 04:58 PM
In Fedora 17, the standard auto-mounting locations for removable media have changed and it's really screwing things up for me here.

My external USB drive now gets mounted to /run/media/<user name>/ and one of my smb mounted network drives gets mounted to /run/user/<user name>/gvfs/

This makes it specifically limited to that particular user for one, and plus it has messed up every script I had that referenced my USB drive mounted in /media.

flyingfsck
8th March 2012, 05:26 PM
Howdy,

That should not happen - should...

The system normally mounts things in /media/volumename, so make sure the devices have volume names.

DBelton
8th March 2012, 05:37 PM
it does have a volume name, but isn't being mounted in /media/volumename. It is being mounted in /run/media/<username>/volumename

Nothing is getting mounted in /media now. (My permanent mounts are in /mnt)

Edit:

I wonder if it has anything to do with this error I have started getting in my ~/.xsession-errors file:


JS ERROR: !!! Exception was: TypeError: Main.automountManager.ckListener is undefined
JS ERROR: !!! lineNumber = '177'
JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/autorunManager.js"'
JS ERROR: !!! stack = '"([object _private_Gio_GUnionVolumeMonitor],[object _private_GObject_GProxyMount])@/usr/share/gnome-shell/js/ui/autorunManager.js:177
wrapper([object _private_Gio_GUnionVolumeMonitor],[object _private_GObject_GProxyMount])@/usr/share/gjs-1.0/lang.js:167
"'
JS ERROR: !!! message = '"Main.automountManager.ckListener is undefined"'

sonoran
8th March 2012, 07:44 PM
I see the same thing for my dvd player. When I insert a disk it is mounted under /run/media/<myusername>/. I don't have any unusual errors in .xsession-errors.

DBelton
8th March 2012, 08:29 PM
Blah.. I don't know what to do about it, either. I have a boatload of USB drives, but only one will be plugged in at a time, so putting them in the /etc/fstab isn't an option since I change up which one is plugged in.

Anyone know where the settings are that it looks at to tell it where to mount the drives? Possibly I could go tweak a config file someplace and get it to put my drives in a known location that doesn't change depending upon user name so that I can access it via my scripts.

Edit:

For the time being, I have come up with a temporary solution.

1: Give all of my USB drives the same volume label
2: mount in /etc/fstab using LABEL=

So, all of my USB drives will now get mounted to the same location when I have it attached. (Since I only use 1 at a time, it will work... I hope :D )

vallimar
9th March 2012, 01:20 PM
It was a change to promote better overall system security.
I don't have the numbers, but I believe they are at least somewhat detailed
in bugzilla for either the gvfs or udisks2 modules as I recall.

DBelton
9th March 2012, 02:56 PM
I guess I just tossed out the "better overall system security" aspect of it :lol:

Now instead of leaving my drives unmounted until I actually needed to use them, I have them mounted all the time through my /etc/fstab.

Some improvement in security :D

sonoran
12th March 2012, 02:04 AM
I wonder if this has anything to do with the issue: http://igurublog.wordpress.com/2012/03/11/udisks2-another-loss-for-linux/

fpmurphy
12th March 2012, 03:40 PM
Yup, it is David Zeuthen again. See http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b.

Apostate
12th March 2012, 10:49 PM
My mount locations change according to how they are mounted. Sometimes they are at /media, sometimes at /run/user/USER/media. Not really very helpful.

DBelton
12th March 2012, 11:04 PM
It's causing a big pain in the butt to have to mount USB drives in /etc/fstab just so you can know where they are going to be mounted :(

Anyway to toss udisks into the bit bucket and use hal again?

(I would also like the old disk utility (palimpsest) as well without the features stripped out of it)

fpmurphy
12th March 2012, 11:18 PM
My mount locations change according to how they are mounted. Sometimes they are at /media, sometimes at /run/user/USER/media. Not really very helpful.
GNOME Shell uses Udisk2, KDE and some other shells still use Udisk1. Both versions can coexist.

deanej
13th March 2012, 01:42 AM
I wonder if this has anything to do with the issue: http://igurublog.wordpress.com/2012/03/11/udisks2-another-loss-for-linux/

I'm starting to think the free software movement needs to declare a war on Gnome. That attitudes of the Gnome developers are contrary to everything free software stands for! It's almost as if they're double agents placed by Microsoft, Apple, and others to slowly turn Linux into proprietary software.

Apostate
13th March 2012, 12:52 PM
GNOME Shell uses Udisk2, KDE and some other shells still use Udisk1. Both versions can coexist.

So use something other than Gnome? Sounds like good advice.

DBelton
13th March 2012, 02:22 PM
So use something other than Gnome? Sounds like good advice.

It's really a sad day when just about every change that they put into Gnome ends up having the same "fiix".... "Use something other than Gnome"

I'm seriously considering going back and installing F14 on my machines here instead of staying with the "bleeding edge"

hostace
14th March 2012, 03:08 PM
This is normal. It's NOT PRODUCTION-READY environment. Just use F16 in other case?

DBelton
14th March 2012, 03:29 PM
no, this is NOT normal.

Normal is a OS that doesn't revert back to things that were fixed years ago.

Normal is to at least be able to use scripts to mount and access a drive for backup purposes.

Normal is to at least have a usable kernel by this stage in the development process.

Normal is having a screen that doesn't revert back to 1024x768 instead of what is read from the monitor EDID upon wakeup after power manager blanks the screen that worked perfectly in previous releases.

Normal is having a system that will start up instead of looping through crashes when a common piece of hardware is attached that worked perfectly in the previous release.

Normal is having it recognize the full speed of the processor and be able to use CPU scaling like worked in F14 instead of it disallowing you to even set the max speed to the full the speed of the processor.

Normal is at least having a mouse that works when using common hardware. In F17, it's a crap-shoot if I get a working mouse when my system boots. Sometimes I do, sometimes I don't.

Normal is at least having a bug report responded to instead of having them sit there for nearly a year without even a response. (Yes, gnome people, I am referring to you here. Other package maintainers seem to at least respond) And yes, those bugs are still bugs.

From the looks of how things are in F17, this may be the very first Fedora release that I haven't used. I have used every Fedora release back to FC1 and before that every redhat release back to 4.1, and yes, I have been through quite a lot of alpha/beta releases along the way as well, so I know what is normal and what is not for a pre-release. And in my opinion, F17 is not even ready for alpha release much less coming up on beta.

hostace
14th March 2012, 03:38 PM
You are using the ALPHA release. Do you know, what it is? I think, do not. In this stage kernel IS USABLE. This is RELEAE CANDIDATE of kernel on kernel.org (!). This is NOT STABLE kernel now. And all other packages may be unstable. This is pre-release of GNOME 3.4 (3.3.91). Do you know, what it's mean? I think, do not. F17 is development version of fedora. And you should not use it, of you need stable operating system. go to wiki and read, what is "bleeding edge". Sorry.

DBelton
14th March 2012, 03:56 PM
Well, since I was writing and using alpha software while you were probably still in diapers, then I would have to say that yes, I do know what alpha is. And yes, the kernel should be in a usable stage, but unfortunately isn't on my system. the rc5 kernel was usable, the rc6 and rc7 kernels are not.

And on the systems where I need a stable OS. I am not using F17 (My main machine is still running F14 and the others are running F16). F17 is only on one test machine.

From the looks of things, F17 is going to be bleeding all the way through it's life cycle.

hostace
14th March 2012, 03:58 PM
the rc5 kernel was usable, the rc6 and rc7 kernels are not.
you may fill bugreport to http://bugzilla.redhat.com

DBelton
14th March 2012, 04:06 PM
Bug has been filed for several weeks now.

(See note above about other bug reports being filed nearly a year ago with NO response, too)

hostace
14th March 2012, 04:11 PM
Thanks for information. I will check them.

AdamW
15th March 2012, 01:37 AM
It may be worth reading http://davidz25.blogspot.com/2012/03/simpler-faster-better.html .

Particularly the bit that starts "Mount and encryption options".

DBelton
15th March 2012, 04:20 AM
That does help a little, Adam.. Thanks. That was what I was looking for.

BUT, something like that article should not be necessary for a graphical disk utility application. They should be self explanatory (like it was in F16)

It sticks a big "-" out that there deletes a partition with no indication of what it is for, but hides useful and safer options behind the cryptic (and duplicated) gears icon.

Really great design :)

fpmurphy
16th March 2012, 02:30 AM
The udisk2 change should have been called out as a new feature in the Fedora 17 project - not just silently slipped into the release by Zeuthen. It is going to effect many people. It also needs to be clearly documented in the Fedora 17 Release Notes.

DBelton
16th March 2012, 02:33 AM
I'm glad that someone else sees it the same way I do :)

While I can see that the new features, etc.. documentation probably is not complete for F17 at this time, that's a big enough change that it should have been in there.

The Gnome developers are getting too good at just slipping new "features" in. :(