| Summary: | unmount of usb sticks and cardreaders broken / eject of of mounted cds broken | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Tobias Powalowski <t.powa> |
| Component: | media | Assignee: | Kevin Ottens <ervin> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | coolo, flameeyes, mueller, rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Tobias Powalowski
2006-07-30 08:56:17 UTC
thanks for the hint with kio_mounthelp program trying as root everything works fine, though it seems to be permission related, i could post some straces to the bugreport, don't know if it would help. our kio_mounthelp is stripped and compiled with debug disabled. my user has rw permissions on usbstick and cd/dvd drives so this shouldn't be the problem. any idea why root is neede to do those unmount tasks? thanks hmm seems, coolo who did the patches, rund hal with --retain-privileges, which means it's run as root. so please fix the behaviour that also distros that don't run hal as root can use the hal stuff. we found a workaround:
--- kdeeject snip
*)
pumount $1 >/dev/null 2>&1
eject $1 >/dev/null 2>&1
;;
-- kdeeject snap
add this in kdeeject and it works again on archlinux
perhaps you know a better way how to fix this.
This explain why unieject worked the problem around: when correctly configured it uses pumount itself. Also Gentoo has HAL running as non-root user, so this is important for us too. I'd need more input: 1) does "dbus-monitor --system" says something while you try to unmount? 2) could you verify that the hal-system-storage* scripts are correctly installed? Hmm, I'm suprised. If I start hald without --retrain-permissions I don't see _any_ of my sda partions so media:/ is empty. So I'm afraid we need to disable HAL support in media for that case. But then again I don't see a difference in HAL properties to find out about that situation. The only noticable difference is that all bios settings are missing if started as non-root - but I guess that can happen on bogus bioses as well. I'll recheck against the latest SVN, but here I'm working without the --retain-privileges option... so I'm really surprised. the packages are correct installed, dbus-monitor --system doesn't show anything as lshal didn'T show anything. our hal maintainer told me that your code calls kdeeject. kdeeject only tries to execute 'eject yourdevice' this fails because fstab is not modified by our hal setup. the workaround with adding pumount to kdeeject works, don't know if this is the final solution for the problem, it's your code and you should understand why it doesn't work on a simple plain/notpatched hal 0.5.7 installation. as i stated before 3.5.3 doesn't show that behaviour and works just fine. gnome-volume-manager and gnome-vfs work correctly too and show partitions without problems. Our setup spawns a specific thing to scan for partitions as root AFAIK root 2270 0.0 0.0 1780 608 ? S 08:05 0:00 /usr/libexec/hald-addon-storage SVN commit 568272 by ervin:
Adding a comment in kdeeject for curious people...
It seems that it's a bug in 'eject' itself introduced between 2.0.13
and 2.1.x. Using 2.0.x or 2.1.5 it works as expected.
CCBUG:131540
M +3 -0 kdeeject
--- branches/KDE/3.5/kdebase/kdeeject/kdeeject #568271:568272
@@ -22,6 +22,9 @@
cdcontrol -f $dev eject >/dev/null 2>&1
;;
*)
+ # Warning, it has to be either eject 2.0.x or >=2.1.5
+ # Otherwise it doesn't work as expected (it requires a
+ # fstab entry for no reason).
eject $1 >/dev/null 2>&1
;;
esac
issue solved, upgrade to eject 2.1.5 or stay with 2.0.13 |