On 07/12/2014 07:34 AM, Brendan McKenna wrote:
In my case, the problem comes up almost as soon as one of the newer kernel versions tries to start one of my hard disk partitions. The boot process doesn't appear to end at that point -- it continues on until it eventually reaches a state where I have a message indicating that there are still two start jobs running (they're trying to start the partitions -- each of them has the LVM name for a hard disk partition associated with it).
Thre was a thread about this a couple or so of months ago, and I've been hit by it too with a recent kernel update. It has to do with the new way LVM is being handled. 'lvm metadata handler' was introduced. There is a setting in /etc/lvm/lvm.conf # Whether to use (trust) a running instance of lvmetad. If this is set to # *and* when lvmetad is running (it is not auto-started), the volume group # metadata and PV state flags are obtained from the lvmetad instance and no # scanning is done by the individual commands. In a setup with lvmetad, # lvmetad udev rules *must* be set up for LVM to work correctly. Without # If lvmetad has been running while use_lvmetad was 0, it MUST be stopped # before changing use_lvmetad to 1 and started again afterwards. It has been set to "1" by some upgrade and unless you have the lvmeta daemon running when you activate the lvm dire things happen. Go to that config and set: use_lvmetad = 0 I got bricked by an upgrade because my root is on lvm. I am very glad, normally, that my root is on lvm, but this came unexpectedly. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- "That's right; the upper-case shift works fine on the screen, but they're not coming out on the damn printer... Hold? Sure, I'll hold." -- e.e. cummings last service call -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org