Bug 742554

Summary:	use the /run directory by default
Product:	[Fedora] Fedora	Reporter:	Michal Schmidt <mschmidt>
Component:	lvm2	Assignee:	Peter Rajnoha <prajnoha>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	agk, bmarzins, bmr, carstenblaauw, dwysocha, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	lvm2-2.02.96-2.fc18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-02 13:16:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michal Schmidt 2011-09-30 14:34:25 UTC

Description of problem:
Instead of:
  /var/lock/lvm
  /var/run/lvm
please configure lvm2 to use by default:
  /run/lock/lvm
  /run/lvm

/run is that it is a read-write dir guaranteed to be available in early boot. The advantage of using /run is that file-based locking will be available all the time, even before /var is available. It should allow us to drop the use of '--sysinit' from the vgchange call in initscripts, making it safer for concurrency.

Version-Release number of selected component (if applicable):
lvm2-2.02.86-5.fc16

Comment 1 Alasdair Kergon 2011-09-30 21:44:43 UTC

currently uses %{_localstatedir}

can certainly replace with whatever spec file macros now expand to those new locations and specify them as defaults set by %configure

This change won't support package upgrade unless we make the code check both old and new locations, so only apply for new installs i.e. rawhide or not-yet-released distro version - no backports to earlier Fedora vsns.

Comment 2 Peter Rajnoha 2012-07-02 13:16:11 UTC

The change is in rawhide now (lvm2-2.02.96-2.fc18), I'll have a look and make sure everything's ready to close bug #742564 as well...