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:
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.
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.
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.
Could we add that to the error message? As Udo said, this problem usually comes up in disaster recovery scenarios where we don't normally have access to the Internet. Write locks are prohibited with read-only locking (override with --config 'global {locking_type=1}' )