Description of problem: mount point devices on F18 are mounted on /run/media so maybe is more useful /media be a symbol link of /run/media/ ln -s /run/media/ / ll /media lrwxrwxrwx 1 root root 11 Mai 22 04:22 /media -> /run/media/ Additional info: /run on F18 is a tmpfs like /tmp , don't know if user could choose other options than not mount on /run/media if so wee need to see if symbol link don't mess with it.
Symlinks in filesystem package are always a bit tricky... but will check what can be done.
not a good idea, because Fedora still contains software that adheres to FHS and works on /media/something anyways, I don't understand what is this change for, where's the feature page, where's FESCO approval on this? - I'd expect exactly opposite bugreport, to bring back proper /media usage instead a bug wishing to finish the destruction of /media ...
Karel, FESCO approves major changes, not such small tunings invisible for users. Such tunings like are not Fedora features - and there is no need for FESCO bureaucracy. With symlink /media -> /run/media , nothing changes for software which works on /media/something - as it will point to /run/media location. Nobody would notice /bin -> /usr/bin without the feature page - as there were no conflicts - such change with /media is even easier, as you don't have Requires/Provides on /media/<something> ... The only thing which may break is script with relative paths (running e.g. ../bin/bash ) - other than that, everything should be unaffected by symlink. For Fedora 20/21 it shouldn't be an issue.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
# yum update filesystem Resolving Dependencies --> Running transaction check ---> Package filesystem.i686 0:3.2-27.fc22 will be updated ---> Package filesystem.i686 0:3.2-28.fc22 will be an update --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Updating: filesystem i686 3.2-28.fc22 rawhide 1.1 M Transaction Summary ======================================================================================================= Upgrade 1 Package Total size: 1.1 M Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction (shutdown inhibited) Transaction couldn't start: file /media from install of filesystem-3.2-28.fc22.i686 conflicts with file from package filesystem-3.2-27.fc22.i686 [('file /media from install of filesystem-3.2-28.fc22.i686 conflicts with file from package filesystem-3.2-27.fc22.i686', (7, '/media', 37015L))]
Yes, replacing dir with symlink - fortunately, this is just for rawhide updates, I'll try to fix it soon (as /media is nowadays empty, most of usecases should be fixed with os.remove("/media") in %pre scriptlet before creating symlink.
filesystem-3.2-29.fc22.i686 updated fine.
/media -> run/media link broken if no one device was mounted because run/media not exists, so maybe it should be created even without any device mounted?
yes, will check the proper way with systemd guys - probably creating file as posttrans in /etc/tmpfiles.d would be the right way.
udisks can be configured (with udev rules) to mount devices under /media. From udisks(8): UDISKS_FILESYSTEM_SHARED If set to 1, the filesystem on the device will be mounted in a shared directory (e.g. /media/VolumeName) instead of a private directory (e.g. /run/media/$USER/VolumeName) when the Filesystem.Mount() method is handled. Having /media as a symlink to /run/media may break this. Also, /run/media != /run/media/$USER, so it's not like the symlink provides us with any kind of backwards compatibility...
Michal, I'm not sure I'm getting correctly why the symlink can break this? IMHO if the tmpfiles.d file creating /run/media during startup is there and UDISKS_FILESYSTEM_SHARED is set to 1, shared directory will be still shared - and mounted to /run/media/VolumeName - and anyone/anything expecting it in /media/VolumeName should succeed. But you are right /run/media != /run/media/$USER - so symlink doesn't help too much...
(In reply to Ondrej Vasik from comment #12) > Michal, I'm not sure I'm getting correctly why the symlink can break this? > IMHO if the tmpfiles.d file creating /run/media during startup is there and > UDISKS_FILESYSTEM_SHARED is set to 1, shared directory will be still shared > - and mounted to /run/media/VolumeName For one, VolumeName may conflict with an existing user's name.
But as /run/media is empty after the reboot as tmpfs, it should be empty if UDISKS_FILESYSTEM_SHARED is set to 1 - with no private disks mounted, right? But yes, it is not perfect.
UDISKS_FILESYSTEM_SHARED can be set per-device. You can have private (mounted under /run/media/$USER) and shared (mounted under /media) devices at the same time.
So - do I get it right your recommendation is to revert the /media -> /run/media change?
Yes, IMO the symlink is not useful, having it there is fragile, and it should be undone. I see two options for /media: 1. Revert it to a directory. 2. Drop it. If we are sure nothing in the distribution needs it. For instance, I'm not sure about "udisks", which we still ship. udisks2's UDISKS_FILESYSTEM_SHARED option is not the default and whoever sets it can also create /media by themselves, so I would not count that.
Ok, I will revert it back to directory, thanks for the comments.
Hi for the record, I found other case : /usr/bin/livecd-iso-to-disk boot.iso /dev/sdb1 mktemp: failed to create directory via template ‘/media/srctmp.XXXXXX’: No such file or directory so I remove rm /media rm: remove symbolic link ‘/media’? y and just after mkdir /media /usr/bin/livecd-iso-to-disk boot.iso /dev/sdb1 worked