Bug 722814 - /var/lock/lockdev is lost after reboot - add to tmpfiles.d
Summary: /var/lock/lockdev is lost after reboot - add to tmpfiles.d
Alias: None
Product: Fedora
Classification: Fedora
Component: lockdev
Version: 14
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-07-18 04:29 UTC by Martin Langhoff
Modified: 2011-07-19 09:05 UTC (History)
11 users (show)

Clone Of:
Last Closed: 2011-07-19 09:05:14 UTC

Attachments (Terms of Use)

Description Martin Langhoff 2011-07-18 04:29:08 UTC
Description of problem:

If the /var/lock/lockdev directory is missing, minicom will error out with "Device /dev/ttyUSB0 lock failed: Operation not permitted."

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Plug a serial adapter on /dev/ttyUSB0
2. minicom -s USB0 to configure it
3. minicom USB0
Additional info:

Installing the lockdev package _or_ creating the /var/lock/lockdev directory fixed the problem.

A simple fix for this would be to add a lockdev dependency to minicom.

Comment 1 Martin Langhoff 2011-07-18 07:09:25 UTC
Actually - after a bit more diagnosis, the dependency is there, and lockdev is installed in the problem machines.

The issue is with /var/lock/lockdev -- it is lost after reboot. Should be declared in a /etc/tmpfiles.d/ directory. Something like 

$ cat /etc/tmpdiles.d/lockdev.conf
d	/var/lock/lockdev	0775 root lock

Comment 2 Peter Robinson 2011-07-18 09:42:17 UTC
Issue exists in rawhide as well.

Comment 3 Jiri Popelka 2011-07-18 12:40:12 UTC
I had dropped /etc/tmpfiles.d/lockdev.conf from lockdev package because of bug #692714. Moving this BZ to systemd which should ship this file in F15.

Comment 4 Martin Langhoff 2011-07-18 16:05:22 UTC
Note that this issue affects F14 as well (and this impacts OLPC OS releases).

Even if systemd gets this fixed on F15/rawhide, F14 needs /etc/tmpfiles.d/lockdev.conf

Comment 5 Lennart Poettering 2011-07-18 20:25:23 UTC
Hmm, /usr/lib/tmpfiles.d/legacy.conf creates that directory, so it should be there. Are you suggesting this file is not existant for you?

Comment 6 Martin Langhoff 2011-07-19 06:21:22 UTC
Actually, you are right, and my repro test on F15 was wrong, so systemd is in the clear. Reassigning to lockdev.

The problem repros on F14 -- the F14 package in fedpkg needs to get some bits from commit 76efe301a85adf8470f72569c6a90d8fd4c2a8e5 .

In other words - the change was applied for F15 and then removed in favour of the systemd fix. That initial change needs to be applied to F14.


Comment 7 Jiri Popelka 2011-07-19 08:56:26 UTC
The https://fedoraproject.org/wiki/Features/var-run-tmpfs
is F15 feature so the /var/lock/lockdev should survive reboot on F14.
Adding /etc/tmpfiles.d/lockdev.conf to F14 doesn't change anything.
Or am I wrong, Lennart ?

Comment 8 Martin Langhoff 2011-07-19 09:04:50 UTC
Gaah. Peter Robinson just pointed out that I see this on F14 because at OLPC we have backported var-run-tmpfs to our custom F14.

So this bug is invalid (in Fedora), and I apologize for having bothered everyone with it. On the upside, you have helped me diagnose a bug in OLPC's build, which is used by >1.5M children around the world .

Thanks for your patience.

Note You need to log in before you can comment on or make changes to this bug.