firmware.agent tries to be smarter than usb.agent. usb.agent gets the path sysfs
is mounted by staticall using /sys.
firmware.agent however does this:
SYSFS=$(sed -n 's/^.* \([^ ]*\) sysfs .*$/\1/p' /proc/mounts)
This works fine as long as sysfs is mounted only ONCE. If its mounted more than
once the variable will contain serveral lines and when used in
cp "$FIRMWARE_DIR/$FIRMWARE" $SYSFS/$DEVPATH/data
cp will silently fail (.../data is a file, and 2 or more files cant be copied to
So either limit the output of $(sed -n 's/^.* \([^ ]*\) sysfs .*$/\1/p'
/proc/mounts) to one line (but make sure this directory is accessible) or skip
it all together and use /sys statically.
The way I encountered the bug was that a genkernel initrd failed to unmount its
/sys and thus I had it mounted twice.
On my desktop machine I've also got it mounted twice, once in my 64bit system
and once in a 32bit chroot. So its not uncommon to have such a situation
Steps to Reproduce:
1. mkdir /mnt/foobar
2. mount sysfs /mnt/foobar -t sysfs
3. do something which will trigger a firmware upload
doesnt work since cp will get passed something like
cp "/lib/firmware/something" /sys/$DEVPATH/ /mnt/foobar/$DEVPATH/data
limit output to one line, either by setting SYSFS=/sys or by testing each
possible line and then using one which will work.
Reopen after you've posted what ebuild and version is this bug about...
Sorry, I though it was clear.
Aw, its sys-apps/hotplug-20040923 (which is the latest version)
sys-apps/hotplug is useless with any recent udev version, and 2.4 kernels are no longer supported. Unmerge it and move on.