This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 865015 - pvcreate: read-only locking selected (in dracut shell)
pvcreate: read-only locking selected (in dracut shell)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 11:51 EDT by udo
Modified: 2012-10-10 13:41 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-10 13:41:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description udo 2012-10-10 11:51:02 EDT
Description of problem:
when running pvcreate in the shell that dracut provides when booting up the system and something's wrong, I get:
read-only locking selected. Only read operations permitted
Write locks are prohibited with read-only locking.
Can't get lock for orphan PVs.

I did not select any locking type. I did not want to work with orphan PVs.
I wanted to write onto an encrypted volume on a raid-5 array using pvcreate which does need write access of course.


Version-Release number of selected component (if applicable):
# rpm -qf `which pvcreate`
lvm2-2.02.95-6.fc17.x86_64


How reproducible:
have diskfailures so that the encrypted raid5 lvm set goes bad; replace bad disks; boot from kernel om raid-1; see dracut shell appear because of bad raid-5.
create raid-5.
create encryption on raid-5. open encrypted volume.
create pv on crypto using pvcreate etc.
(pvcreate /dev/mapper/crypto)

 
Actual results:
See description

Expected results:
pv created

Additional info:
Comment 1 Bryn M. Reeves 2012-10-10 12:05:40 EDT
When dracut builds an initramfs it switches the locking type to type 4 (read-only) since write access is not available during early boot. See /usr/lib/dracut/modules.d/90lvm/module-setup.sh.

You can override the locking type on the command line (or via the config file - set LVM_SYSTEM_DIR if necessary to point the tools to a writable location):

pvcreate --config 'global {locking_type=1}' ...

Obviously the tools will need a writable location (conventionally /var/lock) to place the lock files.

If you're certain nothing else is touching the VG (should be easy to guarantee in the initramfs!) then you could also using locking type 0 (no locks).

Alternately set the VG up from a fully-booted system to avoid having to deal with the quirks of the early userspace boot.
Comment 2 udo 2012-10-10 12:18:17 EDT
Ah..!
The `pvcreate --config 'global {locking_type=1}' ...` solution is the easiest if we can remember that one at disaster-time.
So maybe hard-code this?

Thanks for explaining. 
How to deal with this `bug`?

Obviously we want to be able to use dracut shell to the fullest but not obstruct or endanger normal behaviour.
Comment 3 Alasdair Kergon 2012-10-10 13:41:28 EDT
I'm very reluctant to change anything here.  It behoves anyone using that shell to understand properly the consequences of what they are doing and if that means they have to do some extra typing to workaround sensible early-boot defaults, then so be it.

This bugzilla can stand to help people in a similar situation in future.

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