Red Hat Bugzilla – Bug 98160
minicom fails with port /dev/input/ttyACM0
Last modified: 2012-11-06 21:11:50 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: With minicom setup for the modem port as /dev/input/ttyACM0, invoking the program complains "Device /dev/input/ttyACM0 lock failed: No such file or directory." An strace reveals that minicom is looking for /dev/ttyACM0. Establishing the link /dev/ttyACM0 -> input/ttyACM0 allows minicom to work. Version-Release number of selected component (if applicable): minicom-2.00.0-12 How reproducible: Always Steps to Reproduce: 1. (as root) "minicom -s", set the serial port to /dev/input/ttyACM0, save as default, and exit. 2. Plug in a USB modem, check that it appears in /proc/bus/usb/devices, and that kernel module acm is loaded. 3. Invoke minicom, see complaint and failure exit. 4. cd /dev; ln -s input/ttyACM0 ttyACM0 5. Invoke minicom, see no complaint. Actual Results: First try [after configuration]: Device /dev/input/ttyACM0 lock failed: No such file or directory. Second try: no complaint. Expected Results: No complaint even on first try [after configuration]. Additional info:
Created attachment 92649 [details] /etc/minirc.dfl minicom configuration defaults file showing modem port /dev/input/ttyACM0
Created attachment 92650 [details] strace -f minicom grep for "ACM": ----- [pid 22573] execve("/usr/sbin/lockdev", ["/usr/sbin/lockdev", "-l", "/dev/input/ttyACM0"], [/* 33 vars */]) = 0 [pid 22573] stat64("/dev/ttyACM0", 0xbfff94e0) = -1 ENOENT (No such file or directory) access("/dev/input/ttyACM0", W_OK) = 0 write(2, "Device /dev/input/ttyACM0 lock f"..., 66Device /dev/input/ttyACM0 lock failed: No such file or directory. ----- which shows that the main process found /dev/input/ttyACM0, but the helper [lock] process is looking for /dev/ttyACM0 [without the "/input/" in the middle of the pathname].
reassigning to the dev component-- not sure if the device belongs under input according to the FHS, and if the link needs to exist, the dev component should create it, not minicom
actually, this looks like a bug in lockdev... specifically, _dl_check_devname() in lockdev.c is too aggressive with tty device path rewrites.
fixed in rawhide lockdev-1.0.1-1
Please re-open. Fails under lockdev-1.0.1-1.3, Fedora Core beta2 (kernel 2.4.22-1.2084.nptlsmp and corresponding up2date) because "/var/lock/LCK..input/ttyACM0" cannot be found. That is, lockdev thinks that there should be a subdirectory LCK..input in /var/lock, but such a subdirectory does not exist. strace -f minicom 2>&1 | grep ACM: ----- [pid 6141] execve("/usr/sbin/lockdev", ["/usr/sbin/lockdev", "-l", "/dev/input/ttyACM0"], [/* 30 vars */]) = 0 [pid 6141] stat64("/dev/input/ttyACM0", {st_mode=S_IFCHR|0666, st_rdev=makedev(166, 0), ...}) = 0 [pid 6141] access("/dev/input/ttyACM0", W_OK) = 0 [pid 6141] open("/var/lock/LCK..input/ttyACM0", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 6141] open("/var/lock/LCK..input/ttyACM0", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 6141] link("/var/lock/LCK...6140", "/var/lock/LCK..input/ttyACM0") = -1 ENOENT (No such file or directory) [pid 6141] exit_group(7) = ? access("/dev/input/ttyACM0", W_OK) = 0 write(2, "Device /dev/input/ttyACM0 lock f"..., 66Device /dev/input/ttyACM0 lock failed: No such file or directory. -----
I didn't used the rawhide lockdev. But it worked for me (I made minicom work) creating the /var/lock/LCK..input/ directory.
*** This bug has been marked as a duplicate of 74454 ***