pmount is a helper application for gnome-volume-manager that enables the user to mount hotplugged devices without modifying /etc/fstab with hal's fstab-sync. This method is much cleaner and carries no risk of clobbering the fstab file. Attached is the initial ebuild for pmount version 0.2.2
Created attachment 42977 [details] pmount ebuild
how does it deal with the nonexistant /media on gentoo ?
It fails. If needed, the ebuild could create it. pmount calls mount with the proper options. forgue@roanoke ~ $ sudo mv /media/ /media2 forgue@roanoke ~ $ pmount /dev/sda2 Error: could not create directory: No such file or directory forgue@roanoke ~ $ =*=*= Also, I should add the policy... The mount will succeed if all of the following conditions are met: - <device> is a block device in /dev/ - <device> is not handled by /etc/fstab (if it is, pmount calls '/bin/mount <device>' to handle this transparently; supplying a label is not allowed in this case) - <device> is not already mounted according to /etc/mtab and /proc/mounts - if the mount point already exists, there is no device already mounted at it and the directory is empty - <device> is removable (i. e. on USB or FireWire bus, or /sys/block/drive/removable == 1) - <device> is not locked (see below)
When a removable device gets mounted by pmount, the options are set so that the user that mounted it has rw access, and the mount is set nosuid,noexec,nodev,sync forgue@roanoke ~/pmount-0.2.2 $ pmount /dev/sda2 forgue@roanoke ~/pmount-0.2.2 $ mount | grep sda2 /dev/sda2 on /media/sda2 type vfat (rw,noexec,nosuid,nodev,sync,uid=1001,gid=100,umask=007) In my opinion, these are very good mount options. The only downside is if you want to change them, you have to modify the source. I don't see anyone wanting to do that, they are sane defaults for removable devices.
well i read the policy ofcourse, but /media is more a baselayout thing. I'm not sure it should be world writeable anyway. Can any of the baselayout maintainers comment ?
Well, /media doesn't have to be world writable for this because pmount is setuid.
/media would be the realm of baselayout ... there was discussion about supporting /media on the gentoo-dev mailing list, but nothing was ever really decided so i guess the answer at this point is that we dont support it as for the setuid thing, it should not be done in pkg_postinst(), it should be done in src_install() ...
because nothing needed it, media is FHS and logical to add. If it's not in base we'll just have the ebuild create it. Anyway, the supposed baselayout maintainers were cc-ed ? Last time i was told they were the only ones making the changes & with the supposed load on the base-system team i wasn't gonna CC em, so much for that.
anyone who felt overloaded by base-system has probably left it long ago
ok, i fiddled around a bit with pmount-0.3 today a few things i ran into : * iso9660 mounting fails with the umask it sets * interaction with nautilus is mediocre at best : - devices do not show up - devices cannot unmount * default mount options are indeed hardcoded, wouldn't it be better to follow storage policy * why not use hal-storage (? - i guess this might be on the todo upstream) * the ebuild, why creating a special user ? I know it's somewhat more controlled/secure, but this is about making removable devices 'just work'and you lose that right away. * i'd like to see it only mount in /media .. right now it seems to pick random mount points in /mnt if there are available and this is odd at best Especially the interaction with nautilus is important, since this is primaraly used there at this point. It might be that the hal patch in gnome-vfs-2.8.3 has made matters worse (didn't test without that patch), but that is the way it's gonna go anyway, so it needs to deal with that. @baselayout maintainers : any word on /media added ?
Created attachment 47159 [details] pmount-0.4.4.ebuild Ebuild with plugdev group removed
You can rename the ebuild to 0.7.1 and it will emerge latest version. I think it would be good to have this in portage, as it's one of the methods used to provide auto-mount in the future kde 3.4.0 as described in this document (wiki). It's not official but it works with pmount: http://wiki.kde.org/tiki-index.php?page=DBUS
I have been testing pmount with the new media:/ kioslave in KDE 3.4 and it integrates very well there. I would certainly like to see this get into portage too - if you need any help with it let me know. I am using 0.7.1 right now with no issues so far.
I have installed pmount-0.7.1 alongside hal and dbus and it seems to work well. It produces an icon in konqueror "media:/" when you plug in USB storage or load an optical disk. By setting KDE background to display all devices except hard drives, both mounted and unmounted, everything is smooth. I particularly like that I get an unmounted icon when inserting a device, which I can then mount, unmount as required which disappears when I eject/remove the device. However, the icon seems to be fixed (OK for USB Key, but not very descriptive of a Card Reader), and the name on the icon seems to be taken from the volume of the mounted device. As I have used udev to give all my devices their own names like "/dev/usbstorage/usbkey", is there a file I can use to determine the icon's name and logo when the device is plugged in?
Why does one want to have fstab-sync at all? I think the pmount solution is superior. Modifying fstab doesn't look like an elegant solution at all. What happens when during writing to fstab the machine crashes? It's error prone, isn't it? I think it would be an improvement for the Gentoo desktop to switch to pmount instead of fstab-sync. A virtualization could be added later if there is really demand. Fedora, Debian, SuSE, NDL, and others already switched to pmount, why does Gentoo think fstab-sync is better? Maybe there were some shortcomming with early pmount, but since filing of this bug and #69577 half a year already passed and pmount improved. Are the reasons why Gentoo doesn't switch to pmount are still present, and if yes, what are the reasons? For the record I use pmount 0.7.2 together with KDE 3.4 and it works fine, no problems I am aware of so far.
Created attachment 57417 [details] pmount-0.8.ebuild Fixed issues with the ebuild, version bumped it and added support for creating a symlink for hal in /etc/hal/device.d
Ok. 0.8 is out. Here's a HOWTO for people wanting to try this in KDE: http://gentoo-wiki.com/HOWTO_D-BUS%2C_HAL%2C_KDE_media:/ The ebuild gives QA warnings at the moment: QA Notice: /usr/bin/pmount is setXid, dynamically linked and using lazy bindings. This combination is generally discouraged. Try: CFLAGS='-Wl,-z,now' emerge pmount QA Notice: /usr/bin/pumount is setXid, dynamically linked and using lazy bindings. This combination is generally discouraged. Try: CFLAGS='-Wl,-z,now' emerge pmount So we probably should add these to the CFLAGS in the ebuild, but I will leave this decision to a developer in charge of this.
The pmount-0.8.ebuild works fine here.
Created attachment 58427 [details] pmount-0.8.ebuild
Created attachment 58428 [details, diff] files/pmount-0.8-hal-api.patch
Created attachment 58437 [details] pmount-0.8.ebuild cleaned up.
cardoe: Why did you obsolete my ebuild and not use my enhancements? As far as I understand it, the symlink in /etc/hal/device.d is needed.
That was my change. The symlink is not needed. pmount works differently than fstab-sync in that regard.
Created attachment 58485 [details] A (stable) development snapshot which includes the new api and several small fixes
Maybe this is due to the depend (91928) but I tried the new ebuild, and I get: cc -c -march=i686 -O3 -pipe -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include pmount-hal.c cc pmount.o policy.o utils.o fs.o -lsysfs -o pmount pmount-hal.c: In function `main': pmount-hal.c:167: warning: assignment makes pointer from integer without a cast pmount-hal.c:181: warning: assignment makes pointer from integer without a cast pmount-hal.c:189: warning: assignment makes pointer from integer without a cast pmount-hal.c:191: warning: assignment makes pointer from integer without a cast cc pumount.o policy.o utils.o -lsysfs -o pumount cc -lhal -ldbus-1 pmount-hal.o policy.o utils.o -lsysfs -o pmount-hal pmount-hal.o(.text+0x521): In function `main': : undefined reference to `libhal_ctx_new' pmount-hal.o(.text+0x53d): In function `main': : undefined reference to `libhal_device_exists' pmount-hal.o(.text+0x55c): In function `main': : undefined reference to `libhal_device_property_exists' pmount-hal.o(.text+0x59c): In function `main': : undefined reference to `libhal_ctx_free' pmount-hal.o(.text+0x63c): In function `main': : undefined reference to `libhal_device_get_property_string' pmount-hal.o(.text+0x662): In function `main': : undefined reference to `libhal_device_property_exists' pmount-hal.o(.text+0x685): In function `main': : undefined reference to `libhal_device_property_exists' pmount-hal.o(.text+0x6a8): In function `main': : undefined reference to `libhal_device_property_exists' pmount-hal.o(.text+0x6cb): In function `main': : undefined reference to `libhal_device_property_exists' pmount-hal.o(.text+0x6d7): In function `main': : undefined reference to `libhal_ctx_free' pmount-hal.o(.text+0x731): In function `main': : undefined reference to `libhal_device_get_property_string' pmount-hal.o(.text+0x754): In function `main': : undefined reference to `libhal_device_get_property_bool' pmount-hal.o(.text+0x777): In function `main': : undefined reference to `libhal_device_get_property_bool' pmount-hal.o(.text+0x79a): In function `main': : undefined reference to `libhal_device_get_property_string' collect2: ld returned 1 exit status make: *** [pmount-hal] Error 1
OK, nevermind that. It is fixed with the new ebuild, thanks.
Created attachment 58487 [details] A (stable) development snapshot which includes the new api and several small fixes depend on hal >=0.5
Created attachment 58493 [details] A (stable) development snapshot which includes the new api and several small fixes forgot to dobin pmount-hal
Not really a Gnome herd package... But I've got it covered. InCVS
removed from cvs because of broken dependencies. Needs new hal/dbus. Reassigning to utopia@gentoo.org
pmount-0.9 is out, I tried renaming the last ebuild provided here (http://bugs.gentoo.org/attachment.cgi?id=58493), but it didn't compile on my amd64.
we have it taken care of in the Gentopia overlay. thx.
Could we add a pmount-0.8 ebuild with the old api until the gentopia-stuff is ready? I'm using it with kde, it works nice. AFAIK there is no kde with the new hal-api yet, so I cannot use the gentopia-overlay.
hanno: We have a patched kdebase in the overlay, so if you are interested, go ahead :)
Is the overlay in gentopia only for the non-split ebuilds of KDE?
pmount is now in portage. http://packages.gentoo.org/ebuilds/?pmount-0.9.3
I added it to the Portage tree today. It's masked however.
