Summary: | sys-fs/udisks:2 fails to mount CD first time if it was not mounted before with <sys-fs/udev-180 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | freedesktop-bugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.freedesktop.org/show_bug.cgi?id=52357 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 411627, 427550 | ||
Attachments: | udisksctl dump output |
Description
Pacho Ramos
2012-05-26 12:16:37 UTC
The question that follows is: does 'udisks --mount' (or rather the version of it for udisks2) print anything interesting ? $ udisksctl mount -b /dev/sr0 Object /org/freedesktop/UDisks2/block_devices/sr0 is not a mountable filesystem. Created attachment 313151 [details]
udisksctl dump output
OK, my mistake. I failed to notice "Login in Gnome2" part - that would mean that quite likely things are working as expected - Nautilus in Gnome 2 can't be aware of udisks2. (In reply to comment #4) > OK, my mistake. > I failed to notice "Login in Gnome2" part - that would mean that quite > likely things are working as expected - Nautilus in Gnome 2 can't be aware > of udisks2. Thunar still works fine without any modification, so the compability code should be gvfs internal matter, not related to nautilus Unless nautilus makes direct dbus calls to udisks? That'd be suprising. Try udisks-1.98.0 (In reply to comment #6) > Try udisks-1.98.0 Tried, still the same, libgdu needs to be installed even with gvfs compiled with "-gdu" Steps to reproduce now on my system: 1. Poweroff system 2. Poweron WITHOUT any CD device inserted (if it's inserted while booting it will be properly detected and mounted) 3. Insert CD -> Nothing occurs 4. Run "udisksctl mount -b /dev/sr0", I get: $ udisksctl mount -b /dev/sr0 Object /org/freedesktop/UDisks2/block_devices/sr0 is not a mountable filesystem. 5. Log in as root and manually run: # mount /dev/sr0 /mnt/backups/ mount: warning: /mnt/backups/ seems to be mounted read-only. 6. Umount it -> udisks goes ahead and automounts it! 7. If, now, I unmount it manually and run udisksctl, all goes ok: udisksctl mount -b /dev/sr0 Mounted /dev/sr0 at /run/media/pacho/Gentoo Linux amd64 20120223. On the other hand, old udisks works properly in this same situation: $ udisks --mount /dev/sr0 Mounted /org/freedesktop/UDisks/devices/sr0 at /media/disk I have reported it upstream now that I have found a way to reproduce simply from console, without involving gvfs/nautilus/gnome... simply udisks1 vs udisks2 with my CD device that looks to not be properly detected by udisks2 while works fine with udisks1 With udevil I get it failing on first run and ok on second: $ udevil mount /dev/sr0 udevil: error: no media in device /dev/sr0 (or specify type with -t) $ udevil mount /dev/sr0 Mounted /dev/sr0 at /media/Gentoo Linux amd64 2 But, anyway, even running it only first time (and, then, getting the failure), if I run udisksctl just after that, it's properly mounted :O hasufell kindly pointed me to http://ignorantguru.github.com/udevil/#polling But I don't want to update udev without knowing it won't break anything (since looks like it tends to change a lot of things now :( ) (In reply to comment #12) > hasufell kindly pointed me to http://ignorantguru.github.com/udevil/#polling > > But I don't want to update udev without knowing it won't break anything > (since looks like it tends to change a lot of things now :( ) If it's just a matter of this, the udev rule, that article refers to, is trivial: ACTION=="add", SUBSYSTEM=="module", KERNEL=="block", ATTR{parameters/events_df l_poll_msecs}=="0", ATTR{parameters/events_dfl_poll_msecs}="2000" Basically, that's echo "2000" > /sys/module/block/parameters/events_dfl_poll_msecs (well, more or less). (In reply to comment #12) > hasufell kindly pointed me to http://ignorantguru.github.com/udevil/#polling > > But I don't want to update udev without knowing it won't break anything > (since looks like it tends to change a lot of things now :( ) we already check for this to be enabled from sys-apps/dbus ebuild: ssuominen@null ~/gentoo-x86 $ grep -r EPOLL */*/*.ebuild sys-apps/dbus/dbus-1.6.0.ebuild: CONFIG_CHECK="~EPOLL" sys-apps/dbus/dbus-1.6.2.ebuild: CONFIG_CHECK="~EPOLL" sys-apps/dbus/dbus-1.6.4.ebuild: CONFIG_CHECK="~EPOLL" ssuominen@null /tmp/libindicate-0.6.1 $ cat /sys/module/block/parameters/events_dfl_poll_msecs 2000 success...? (In reply to comment #14) > (In reply to comment #12) > > hasufell kindly pointed me to http://ignorantguru.github.com/udevil/#polling > > > > But I don't want to update udev without knowing it won't break anything > > (since looks like it tends to change a lot of things now :( ) > > we already check for this to be enabled from sys-apps/dbus ebuild: > > ssuominen@null ~/gentoo-x86 $ grep -r EPOLL */*/*.ebuild > sys-apps/dbus/dbus-1.6.0.ebuild: CONFIG_CHECK="~EPOLL" > sys-apps/dbus/dbus-1.6.2.ebuild: CONFIG_CHECK="~EPOLL" > sys-apps/dbus/dbus-1.6.4.ebuild: CONFIG_CHECK="~EPOLL" > I have it enabled: CONFIG_EPOLL=y > ssuominen@null /tmp/libindicate-0.6.1 $ cat > /sys/module/block/parameters/events_dfl_poll_msecs > 2000 > > success...? No :( $ cat /sys/module/block/parameters/events_dfl_poll_msecs 0 Probably a newer udev is needed? I have stable 171-r6 As I already said, the only part that the more recent udev does is setting the value to 2000 if it's unset ('0'), the rest is udisks. After a reboot, just echo such value to /sys/module/block/parameters/events_dfl_poll_msecs (perhaps you need to do it before udisks runs, but that should be all) and see if things work. Upstream thinks this is caused by udev not being started properly and, then, ID_FS* properties not being available for sr0 https://bugs.freedesktop.org/show_bug.cgi?id=52357#c6 Could this be related with this udev-180 change? udev 180 34 ======== 35 Fix for ID_PART_ENTRY_* property names, added by the blkid built-in. The 36 fix is needed for udisk2 to operate properly. (In reply to comment #18) > Could this be related with this udev-180 change? You tell me after testing. I have no problems with forcing >=sys-fs/udev-180 in the udisks ebuild, mixing is not supported anyways. (In reply to comment #19) > (In reply to comment #18) > > Could this be related with this udev-180 change? > > You tell me after testing. I have no problems with forcing >=sys-fs/udev-180 > in the udisks ebuild, mixing is not supported anyways. This question was more oriented to udev maintainers that will probably know better more about this udisks2/udev interaction than me :( I am still running stable udev because most of my system is stable. I have no separate /usr partition, is there any other important change with newer udev versions that are preventing it from being stabilized? (In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > Could this be related with this udev-180 change? > > > > You tell me after testing. I have no problems with forcing >=sys-fs/udev-180 > > in the udisks ebuild, mixing is not supported anyways. > > This question was more oriented to udev maintainers that will probably know > better more about this udisks2/udev interaction than me :( I don't know anything about udisks2, so testing this would be helpful. > I am still running stable udev because most of my system is stable. I have > no separate /usr partition, is there any other important change with newer > udev versions that are preventing it from being stabilized? I have a couple of bugs in 186 that I want to address in 187, but besides that, there isn't anything. All looks fixed with sys-fs/udev-186 :D The problem now is how far is udev-186 (and co, like newer openrc) stabilization :/ Since I will be out since tomorrow to Sep 10, I doubt if we could delay so much bug 427544, probably yes but, if not, maybe we could stabilize that new set if profile change to use udisks2 over gdu for gvfs is reverted and postponed until newer udev can be stabilized. What do you think? Of course, the ideal would be to start udev-186 stabilization sooner... but I have no idea about its status (specially that documentation updates that are pending for arches I don't run at all and, then, I cannot help with :( ) (In reply to comment #22) > All looks fixed with sys-fs/udev-186 :D + 02 Aug 2012; Samuli Suominen <ssuominen@gentoo.org> udisks-1.99.0.ebuild: + Force at least sys-fs/udev >= 180 for ID_PART_ENTRY_* property names wrt + #417629 by Pacho Ramos http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udisks/udisks-1.99.0.ebuild?r1=1.2&r2=1.3 |