I have the following problem: I have a machine running arch and which contains a encrypted LV in a LVM. Inside the (encrypted) LV is another PV located. So I have in fact two VGs: One which contains the unencrypted data and one that contains only encrypted data.

I am now trying to get things running smoothly. I have scripts to scan for the PV in the encrypted volume and mount things. Unfortunately this does not work well due to timing problems.

As far as I can tell, when I invoke pvscan, vgscan or lvscan the disks are searched for a LVM signature and if such is found the new VG is activated. This works so far. Then udev is notified and creates different links under /dev. Unfortunately this happens asynchronously. Thus my script continued running and did not find the links needed to check/mount the file systems.

So my questions:

  • Is there a possibility to wait for udev until all links are generated and ready to be used?
  • Is there a possibility to register a rule in udev that will call a script with all links as parameters/environ variables/...?
  • Is there a possibility to register a rule that matches a link generated via udev instead the block device itself?
  • Is there a way to wait until vgscan & Co. have terminated and udev has settled?

If you have another idea, I would like to hear it.

  • LVM inside LVM is very unusual, so I would not be surprised if it was not supported by default. Also when the first disk dies (with the LUKS header), you lose everything. Most people encrypt the PVs or specific LVs. Mar 10, 2016 at 20:54
  • Hello, the encryption is not LUKS but plain crypt. Further you lose you VG in case your encrypted PV dies. It is all the same. Mar 11, 2016 at 19:07
  • If you have multiple encrypted PV, you only lose the LV that was actually located on the lost PV and keep the others. If you make LVM stretch multiple PV first, encrypt that, and LVM it again, it's a bit different... anyway, good reason not to stick to standard solution? None of my business I guess, not sure if you'll get an answer. Good luck. Mar 11, 2016 at 19:14
  • @frostschutz The reason is that I want to have the advantage of lvm to be able to expand a partition on-the-fly. Now not all my partitions must be encrypted. In fact only a subset can be encrypted or I get other problems with the booting (other issue I solved already). To be free how much memory is encrypted I created the unencrypted LVs and one big LV for the encrypted PV. If I encrypted the PVs directly, I had to decide on the sizes of both parts (encrypted and not encrypted) a priori. Mar 17, 2016 at 10:22

1 Answer 1


Your setup is a bit unusual (LVM inside LVM).

In general you should rely on udev as much as possible and not rely on your own scripts too much, i.e. trigger one action and let udev/systemd handle the rest in an event-triggered manner (instead of sequentially running commands in some script)! Also take care to scan only your device and not "everything".

You may also read 69-lvm-metad.rules and use udevadm monitor to see what is happening.

Still I will answer some of your questions as well.

Running a script for a device node

To run a script you can use RUN in an udev-rule. Note that RUN is asynchronous and is run after the rule has been processed (in contrast to PROGRAM)

ACTION=="add", KERNEL=="sdb", RUN+="/usr/local/bin/some_script"

udev will call your script with environment variables in accordance to the variables in your udev-event, i.e. KERNEL, ACTION etc.

You can also match for a symlink, of course, but in order to get your job done I would match against the actual device and probably specify it further instead of relying on the name of a symlink. You can use udevadm monitor --property to see the different events including their properties (unique ids etc.) Also note that the links get appended, so it might be difficult to match (have not checked this myself).

       Match the name of a symlink targeting the node. It can be used once a SYMLINK key has been set in one of the preceding
       rules. There may be multiple symlinks; only one needs to match.

Waiting for udev events to be handled

udevadm settle

will block until all udev events are handled. It also has parameters for a timeout or to wait for a specific file to appear, but for your use case running it without parameters should be enough.

Quoting the udevadm-manpage:

udevadm settle [options]
    Watches the udev event queue, and exits if all current events are handled.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.