| Summary: | pmount doesn't work with 2.6.25 kernels (with deprecated sysfs off?) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
| Component: | Current packages | Assignee: | Greg Kroah-Hartman (RETIRED) <gregkh> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | base-system, gentoo, kernel, leon+gentoo, mgorny, openhs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 218127 | ||
| Attachments: | Patch to sysfsutils fixing pmount for 2.6.25 | ||
|
Description
Petteri Räty (RETIRED)
2008-05-05 10:47:25 UTC
Can't turn the deprecated sysfs stuff for IDE bits off. That's a known thing. That being said, if you actually use this package and want to maintain it. Please feel free to take it. I haven't used it or built it on my machine in over a year. (In reply to comment #1) > Can't turn the deprecated sysfs stuff for IDE bits off. That's a known thing. > That being said, if you actually use this package and want to maintain it. > Please feel free to take it. I haven't used it or built it on my machine in > over a year. > What do you suggest for command line mounting instead? To me, it rather looks like an bug in -lsysfs, where sysfs_get_link() incorrectly resolves last-level, relative symbolic link without resolving higher ones.
$ strace pmount /dev/sdc1
[…]
readlink("/sys/block/sdc/device", "../../../4:0:0:0", 256) = 16
lstat("/4:0:0:0", 0x7fff18645f00) = -1 ENOENT (No such file or directory)
[…]
(In reply to comment #2) > (In reply to comment #1) > > Can't turn the deprecated sysfs stuff for IDE bits off. That's a known thing. > > That being said, if you actually use this package and want to maintain it. > > Please feel free to take it. I haven't used it or built it on my machine in > > over a year. > > > > What do you suggest for command line mounting instead? this app along with ivman. I just have no need for command line mounting for a while which is why I offered you to take it over. > (In reply to comment #3) > To me, it rather looks like an bug in -lsysfs, where sysfs_get_link() > incorrectly resolves last-level, relative symbolic link without resolving > higher ones. > > $ strace pmount /dev/sdc1 > […] > readlink("/sys/block/sdc/device", "../../../4:0:0:0", 256) = 16 > lstat("/4:0:0:0", 0x7fff18645f00) = -1 ENOENT (No such file or directory) > […] > My first thought was that upgrading to 2.6.25 broke this but perhaps it was pciutils-3.0.0 (In reply to comment #5) > > My first thought was that upgrading to 2.6.25 broke this but perhaps it was > pciutils-3.0.0 > plah I mean sysfsutils. But looking at qlop -l doesn't look like it: Tue Jan 30 18:56:31 2007 >>> sys-fs/sysfsutils-2.1.0 I'm just about to slaughter a few (dozen) people, but I think I figured it out. One of the things pmount does is call sysfs_open_device_path after calling sysfs_get_link. The problem is that i.e. I've got /sys/block/sr0, for /sys/block/sr0/device, sysfs_get_link returns ../../../2:0:0:0 Well, the catch is that this breaks sysfs_open_device_path, cause it expects a dir (checked by sysfs_path_is_dir) and then it should call sysfs_get_name_from_path which seems to transform that dir to bus_id, which we already got (2:0:0:0). I think this should work again if in sysfs_open_device_path we drop sysfs_path_is_dir. Of course, this will probably make the modified sysfsutils incompatible with earlier kernels. Actually, it's lstat in sysfs_path_is_dir that fails. Created attachment 152337 [details, diff]
Patch to sysfsutils fixing pmount for 2.6.25
OK, I don't know what this patch breaks, but it fixes pmount.
It looks like a better patch was posted to the project's mailing list. It at http://sourceforge.net/mailarchive/forum.php?thread_name=87skwmofp8.fsf%40denkblock.local&forum_name=linux-diag-devel Not really sure why base-system is CC'd on here. And I'm no longer interested in this package as stated in comment #1. I actually would be in favor of kicking it from gentopia to maintainer-needed... steev? compnerd? The real problem is that this is NOT pmount but, it's sysfsutils one. (In reply to comment #11) > Not really sure why base-system is CC'd on here. And I'm no longer interested > in this package as stated in comment #1. I actually would be in favor of > kicking it from gentopia to maintainer-needed... steev? compnerd? > for sysfsutils And now for something special. Straight from kernel Documentation/sysfs-rules.txt (2.6.26, quote): - Do not use libsysfs It makes assumptions about sysfs which are not true. Its API does not offer any abstraction, it exposes all the kernel driver-core implementation details in its own API. Therefore it is not better than reading directories and opening the files yourself. Also, it is not actively maintained, in the sense of reflecting the current kernel development. The goal of providing a stable interface to sysfs has failed; it causes more problems than it solves. It violates many of the rules in this document. don't use sysfsutils, it's abandonded, broken, and useless. The latest version of pmount in the tree (currently keyworded), no longer uses sysfsutils, and now works correctly when depreciated sysfs stuff is switched off. |
