[arch-general] USB mounted into "wrong" directory
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug? Detailed information: OS: Archlinux x86_64 Repos: testing core extra community{,-testing} multilib{,-testing} Rel. soft: udev 181-9 systemd 44-4 libsystemd 44-4 initscripts-systemd v44.1-1 udisk 1.0.4-3 udisk2 1.93.0-1 The following packages (mentioned above) have been updated: 2012-04-02 ---------- udev 181-5 -> 181-9 libsystemd 44-1 -> 44-3 -> 44-4 udisk2 N/A -> 1.93.0-1 systemd 44-1 -> 44-3 -> 44-4 initscripts-systemd v38-2 -> v44-1 -> v44-2 -> v44.1-1 systemd-arch-units 20120317-1 -> 20120401-1 udisks 1.0.4-2 -> 1.0.4-3 How I mounting USB flash I run Openbox with autostarted dbus and consolekit (my user added to group 'storage'), I run pcmanfm or thunar or nautilus, plugin USB mounting it clikcing on label on left. P.S. Interestingly, mounting in Dolphin works as usual (flashes are mounted in /media/LABEL). --- WBR, Vladimir Lomov -- Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
On Apr 4, 2012 4:46 AM, "Vladimir Lomov" <lomov.vl@gmail.com> wrote:
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug?
This is intentional. It is done by udisks2, while udisks still uses the old location (as fast as I know).
Detailed information: OS: Archlinux x86_64 Repos: testing core extra community{,-testing} multilib{,-testing} Rel. soft: udev 181-9 systemd 44-4 libsystemd 44-4 initscripts-systemd v44.1-1 udisk 1.0.4-3 udisk2 1.93.0-1
The following packages (mentioned above) have been updated: 2012-04-02 ---------- udev 181-5 -> 181-9 libsystemd 44-1 -> 44-3 -> 44-4 udisk2 N/A -> 1.93.0-1 systemd 44-1 -> 44-3 -> 44-4 initscripts-systemd v38-2 -> v44-1 -> v44-2 -> v44.1-1 systemd-arch-units 20120317-1 -> 20120401-1 udisks 1.0.4-2 -> 1.0.4-3
How I mounting USB flash
I run Openbox with autostarted dbus and consolekit (my user added to group 'storage'), I run pcmanfm or thunar or nautilus, plugin USB mounting it clikcing on label on left.
P.S. Interestingly, mounting in Dolphin works as usual (flashes are mounted in /media/LABEL).
--- WBR, Vladimir Lomov
-- Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
On Wed, 04 Apr 2012 12:05:55 +0300, Tom Gundersen <teg@jklm.no> wrote:
On Apr 4, 2012 4:46 AM, "Vladimir Lomov" <lomov.vl@gmail.com> wrote:
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug?
This is intentional. It is done by udisks2, while udisks still uses the old location (as fast as I know).
Uh, is there any way to revert to old mapping? I do not like the new one. ~David
Detailed information: OS: Archlinux x86_64 Repos: testing core extra community{,-testing} multilib{,-testing} Rel. soft: udev 181-9 systemd 44-4 libsystemd 44-4 initscripts-systemd v44.1-1 udisk 1.0.4-3 udisk2 1.93.0-1
The following packages (mentioned above) have been updated: 2012-04-02 ---------- udev 181-5 -> 181-9 libsystemd 44-1 -> 44-3 -> 44-4 udisk2 N/A -> 1.93.0-1 systemd 44-1 -> 44-3 -> 44-4 initscripts-systemd v38-2 -> v44-1 -> v44-2 -> v44.1-1 systemd-arch-units 20120317-1 -> 20120401-1 udisks 1.0.4-2 -> 1.0.4-3
How I mounting USB flash
I run Openbox with autostarted dbus and consolekit (my user added to group 'storage'), I run pcmanfm or thunar or nautilus, plugin USB mounting it clikcing on label on left.
P.S. Interestingly, mounting in Dolphin works as usual (flashes are mounted in /media/LABEL).
--- WBR, Vladimir Lomov
-- Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
-- Using Opera's revolutionary email client: http://www.opera.com/mail/
Looking at your originating mail, you seem to have both udisks and udisks2 installed. Simply removing udisk2 and sticking with udisks should be sufficient here. 2012/4/4, David <pixelshuck@gmail.com>:
On Wed, 04 Apr 2012 12:05:55 +0300, Tom Gundersen <teg@jklm.no> wrote:
On Apr 4, 2012 4:46 AM, "Vladimir Lomov" <lomov.vl@gmail.com> wrote:
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug?
This is intentional. It is done by udisks2, while udisks still uses the old location (as fast as I know).
Uh, is there any way to revert to old mapping? I do not like the new one.
~David
Detailed information: OS: Archlinux x86_64 Repos: testing core extra community{,-testing} multilib{,-testing} Rel. soft: udev 181-9 systemd 44-4 libsystemd 44-4 initscripts-systemd v44.1-1 udisk 1.0.4-3 udisk2 1.93.0-1
The following packages (mentioned above) have been updated: 2012-04-02 ---------- udev 181-5 -> 181-9 libsystemd 44-1 -> 44-3 -> 44-4 udisk2 N/A -> 1.93.0-1 systemd 44-1 -> 44-3 -> 44-4 initscripts-systemd v38-2 -> v44-1 -> v44-2 -> v44.1-1 systemd-arch-units 20120317-1 -> 20120401-1 udisks 1.0.4-2 -> 1.0.4-3
How I mounting USB flash
I run Openbox with autostarted dbus and consolekit (my user added to group 'storage'), I run pcmanfm or thunar or nautilus, plugin USB mounting it clikcing on label on left.
P.S. Interestingly, mounting in Dolphin works as usual (flashes are mounted in /media/LABEL).
--- WBR, Vladimir Lomov
-- Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
-- Using Opera's revolutionary email client: http://www.opera.com/mail/
On Apr 4, 2012 11:14 AM, "David" <pixelshuck@gmail.com> wrote:
On Wed, 04 Apr 2012 12:05:55 +0300, Tom Gundersen <teg@jklm.no> wrote:
On Apr 4, 2012 4:46 AM, "Vladimir Lomov" <lomov.vl@gmail.com> wrote:
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug?
This is intentional. It is done by udisks2, while udisks still uses the old location (as fast as I know).
Uh, is there any way to revert to old mapping? I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might work for the time being /media is going away in the future as the old implementation had issues (namespace and privacy in particular). If you have concerns about the new approach I suggest raising them sooner rather than later, before things become hard to change. Note that in most cases the location of this folder is not something the user sees.
Detailed information: OS: Archlinux x86_64 Repos: testing core extra community{,-testing} multilib{,-testing} Rel. soft: udev 181-9 systemd 44-4 libsystemd 44-4 initscripts-systemd v44.1-1 udisk 1.0.4-3 udisk2 1.93.0-1
The following packages (mentioned above) have been updated: 2012-04-02 ---------- udev 181-5 -> 181-9 libsystemd 44-1 -> 44-3 -> 44-4 udisk2 N/A -> 1.93.0-1 systemd 44-1 -> 44-3 -> 44-4 initscripts-systemd v38-2 -> v44-1 -> v44-2 -> v44.1-1 systemd-arch-units 20120317-1 -> 20120401-1 udisks 1.0.4-2 -> 1.0.4-3
How I mounting USB flash
I run Openbox with autostarted dbus and consolekit (my user added to group 'storage'), I run pcmanfm or thunar or nautilus, plugin USB
mounting
it clikcing on label on left.
P.S. Interestingly, mounting in Dolphin works as usual (flashes are mounted in /media/LABEL).
--- WBR, Vladimir Lomov
-- Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
-- Using Opera's revolutionary email client: http://www.opera.com/mail/
Hello, ** Tom Gundersen [2012-04-04 13:03:19 +0200]:
On Apr 4, 2012 11:14 AM, "David" <pixelshuck@gmail.com> wrote:
On Wed, 04 Apr 2012 12:05:55 +0300, Tom Gundersen <teg@jklm.no> wrote:
On Apr 4, 2012 4:46 AM, "Vladimir Lomov" <lomov.vl@gmail.com> wrote:
Hello, after system upgrade (seems after 2012-04-02) all USB flashes are mounted in /run/media/USER/LABEL instead of /media/LABEL that was previously. Is it intentional or is it a bug?
This is intentional. It is done by udisks2, while udisks still uses the old location (as fast as I know).
Uh, is there any way to revert to old mapping? I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might work for the time being /media is going away in the future as the old implementation had issues (namespace and privacy in particular).
I like idea, but the path is [too] long.
If you have concerns about the new approach I suggest raising them sooner rather than later, before things become hard to change.
Note that in most cases the location of this folder is not something the user sees.
It depends. I usually mount USB flash using pcmanfm, thunar or nautilus then run krusader (doh, until now I didn't know how to mount USB sticks using krusader) and work with the stick. Nevermind, krusader like dolphin uses /media to mount USB sticks. So, I assume in future releases of dolphin and krusader both will use udisks2 and therefore /run/media/USER/LABEL. --- WBR, Vladimir Lomov -- Prunes give you a run for your money.
On Wed, Apr 4, 2012 at 2:09 PM, Vladimir Lomov <lomov.vl@gmail.com> wrote:
It depends. I usually mount USB flash using pcmanfm, thunar or nautilus then run krusader (doh, until now I didn't know how to mount USB sticks using krusader) and work with the stick.
Nevermind, krusader like dolphin uses /media to mount USB sticks. So, I assume in future releases of dolphin and krusader both will use udisks2
I assume so.
and therefore /run/media/USER/LABEL.
In that case they'll use whatever udisks2 uses, yes. AFAIU the current dir might be a stop-gap solution, and the devs are considering using $XDG_RUNTIME_DIR/media/LABEL in the end. That would mean: /run/USER/media/LABEL. -t
On 2012-04-04 15:20, Tom Gundersen wrote:
In that case they'll use whatever udisks2 uses, yes. AFAIU the current dir might be a stop-gap solution, and the devs are considering using $XDG_RUNTIME_DIR/media/LABEL in the end. That would mean: /run/USER/media/LABEL.
No, AFAIK, $XDG_RUNTIME_DIR/media was considered but later rejected for security reasons: * freedesktop/udisks: aa02e5f Use /run/media/$USER for mounting ffbee04 Avoid using $XDG_RUNTIME_DIR/media for now * gnome/gvfs: 6307d01 Use /run/media/$USER instead of $XDG_RUNTIME_DIR/media
commit 6307d017a12642e71ba2f04e82fc3781425a3eb6 Author: David Zeuthen <davidz@redhat.com> Date: Wed Feb 22 17:12:44 2012 -0500
Use /run/media/$USER instead of $XDG_RUNTIME_DIR/media
This is because of security concerns - it is way too dangerous to let a system-daemon such as udisks manage directories in a user-controlled location such as $XDG_RUNTIME_DIR. So now udisks2 is using /run/media/$USER instead, see
http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed...
These bugs are related
https://bugzilla.gnome.org/show_bug.cgi?id=669797 https://bugzilla.gnome.org/show_bug.cgi?id=646391
-- Mantas Mikulėnas <grawity@gmail.com>
On Wed, 4 Apr 2012 14:20:01 +0200 Tom Gundersen wrote:
In that case they'll use whatever udisks2 uses, yes.
Does udisk2 support custom filesystem options? Though to be honest I'll probably stick with my udev rules anyway as I much prefer guaranteed easy to type directory names like /media/usb[0-99] and my rules automount without X ;-).
On Wed, 4 Apr 2012 18:44:33 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Wed, 4 Apr 2012 14:20:01 +0200 Tom Gundersen wrote:
In that case they'll use whatever udisks2 uses, yes.
Does udisk2 support custom filesystem options? Though to be honest I'll probably stick with my udev rules anyway as I much prefer guaranteed easy to type directory names like /media/usb[0-99] and my rules automount without X ;-).
Probably yes, because udisks1 does. However, a better question is whether gvfs will support such options (I don't think it does now). I don't mind using udisks from cli, but I still have to revert to pmount/gvfs for luks-encrypted drivers because udisks can't prompt for a passphrase. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
It would appear that on Apr 4, Tom Gundersen did say:
On Apr 4, 2012 11:14 AM, "David" <pixelshuck@gmail.com> wrote:
Uh, is there any way to revert to old mapping? I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might work for the time being /media is going away in the future as the old implementation had issues (namespace and privacy in particular). If you have concerns about the new approach I suggest raising them sooner rather than later, before things become hard to change.
Pardon me for jumping in here, but you just reminded me that I read somewhere that /media is going away. Can't say that THAT in it self bothers me, since I don't use it. But I've been not allowing anything to auto-mount usb devices for so long now that I've forgotten what (if anything) I had to do to prevent it in Arch {or for that mater any of the other Linux that I multi-boot...} My method of dealing with usb sticks/drives etc, is that if root hasn't found the time to set up a custom fstab entry based on either LABEL=UniquePartitionName for approved usb drives, or /dev/disk/by-id for approved usb sticks, then only by getting root to proactively do something about it do I want the durned thing mounted at all. My fstab method allows for custom mount points where the user simply issues a "mount mountpoint" and/or "umount mountpoint" command to access the approved device. I usually do this from mc where the <alt>+<enter> binding will paste the mountpoint dirname to the command line... Anyway my only concern with the changes that are driving the demise of media is that I'm hoping they won't result in automatic reactivation of auto mounting tools that I don't want, don't use, don't understand, and mostly don't remember how to disable... Do you know if I'm going to have to go there again??? -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>
On Apr 5, 2012 4:17 PM, "Joe(theWordy)Philbrook" <jtwdyp@ttlc.net> wrote:
It would appear that on Apr 4, Tom Gundersen did say:
On Apr 4, 2012 11:14 AM, "David" <pixelshuck@gmail.com> wrote:
Uh, is there any way to revert to old mapping? I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might work for the time being /media is going away in the future as the old implementation had issues (namespace and privacy in particular). If you have concerns about the new approach I suggest raising them sooner
rather
than later, before things become hard to change.
Pardon me for jumping in here, but you just reminded me that I read somewhere that /media is going away. Can't say that THAT in it self bothers me, since I don't use it. But I've been not allowing anything to auto-mount usb devices for so long now that I've forgotten what (if anything) I had to do to prevent it in Arch {or for that mater any of the other Linux that I multi-boot...} My method of dealing with usb sticks/drives etc, is that if root hasn't found the time to set up a custom fstab entry based on either LABEL=UniquePartitionName for approved usb drives, or /dev/disk/by-id for approved usb sticks, then only by getting root to proactively do something about it do I want the durned thing mounted at all. My fstab method allows for custom mount points where the user simply issues a "mount mountpoint" and/or "umount mountpoint" command to access the approved device. I usually do this from mc where the <alt>+<enter> binding will paste the mountpoint dirname to the command line...
Anyway my only concern with the changes that are driving the demise of media is that I'm hoping they won't result in automatic reactivation of auto mounting tools that I don't want, don't use, don't understand, and mostly don't remember how to disable...
Do you know if I'm going to have to go there again???
Nothing should ever require you to disable automounting. The default should be not to mount new devices, anything else sounds like a bug to me.
On Thu, Apr 05, 2012 at 08:10:59PM +0200, Tom Gundersen wrote:
Nothing should ever require you to disable automounting. The default should be not to mount new devices, anything else sounds like a bug to me.
-1
Op 6 apr. 2012 10:56 schreef "Martti Kühne" <mysatyre@gmail.com> het volgende:
On Thu, Apr 05, 2012 at 08:10:59PM +0200, Tom Gundersen wrote:
Nothing should ever require you to disable automounting. The default
should
be not to mount new devices, anything else sounds like a bug to me.
-1
I agree. If a Desktop application wants to automount devices, it's fine. Of course, it would be nice if the user keeps control over this. Besides the desktop environment automounting should *not* occur unless configured by the sysadmin. That way, everybody's happy and the system stays predictable IMHO. mvg, Guus
It would appear that on Apr 6, Guus Snijders did say:
Op 6 apr. 2012 10:56 schreef "Martti Kühne" <mysatyre@gmail.com> het volgende:
On Thu, Apr 05, 2012 at 08:10:59PM +0200, Tom Gundersen wrote:
Nothing should ever require you to disable automounting. The default
should
be not to mount new devices, anything else sounds like a bug to me.
-1
I agree. If a Desktop application wants to automount devices, it's fine. Of course, it would be nice if the user keeps control over this.
Besides the desktop environment automounting should *not* occur unless configured by the sysadmin.
That way, everybody's happy and the system stays predictable IMHO.
I'm glad to hear that's how the smart guys on Arch feel about it. It has been quite some time since I had a problem with it. It's quite possible that the faded memory was from a time before I tried Arch. It's certain that a similar issue of some pop-up wanting to help me deal with a CD or DVD I'd just inserted, annoyed me far more often than Thane ever did with am inserted sub stick... But that, likewise, hasn't happened in a long time. Guess I was just being nervous about nothing... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>
On Thu, 5 Apr 2012 20:10:59 +0200 Tom Gundersen <teg@jklm.no> wrote:
Nothing should ever require you to disable automounting. The default should be not to mount new devices, anything else sounds like a bug to me.
-1 Pete . -- Linux 7-of-9 3.2.13-1-ARCH #1 SMP PREEMPT Sat Mar 24 09:10:39 CET 2012 x86_64 AMD Phenom(tm) 9600B Quad-Core Processor AuthenticAMD GNU/Linux
I am not sure where i should ask question like that, please tell me if its shouldn't be there. I have installed Awesome WM, and now i get very strange artifacts while resizing or moving windows OR having mplayer on full screen gives a lot of huge lines and flicker, making it impossible to watch movies. Nvidia 9500m proprietary driver. -ck kernel(vanilla has this issue too) Thanks for reading ~David
I am not sure where i should ask question like that, please tell me if its shouldn't be there.
it seems to be related to awesome. You should probably ask it on it's mailing list or IRC channel listed here: http://awesome.naquadah.org/community/
On 04/04/2012 09:15 PM, David wrote:
I have installed Awesome WM, and now i get very strange artifacts while resizing or moving windows OR having mplayer on full screen gives a lot of huge lines and flicker, making it impossible to watch movies.
Nvidia 9500m proprietary driver. -ck kernel(vanilla has this issue too)
I had similar problems with Nvidia 9300m + awesome + vanilla kernel. Problems vanished when I started using uvesafb [1]. Not sure if it was awesome-related and if another WM or DE has similar problems (didn't try anything else). [1] https://wiki.archlinux.org/index.php/Uvesafb
participants (13)
-
ali.mousavi＠gmail.com
-
Carlchristian Eckert
-
David
-
Guus Snijders
-
Jochen Maes (Gcool)
-
Joe(theWordy)Philbrook
-
Kevin Chadwick
-
Leonid Isaev
-
Mantas M.
-
Martti Kühne
-
P .NIKOLIC
-
Tom Gundersen
-
Vladimir Lomov