Bug ID | 982329 |
---|---|
Summary | lvmetad doesn't activate volumes |
Classification | openSUSE |
Product | openSUSE Tumbleweed |
Version | Current |
Hardware | x86-64 |
OS | Other |
Status | NEW |
Severity | Major |
Priority | P5 - None |
Component | Basesystem |
Assignee | bnc-team-screening@forge.provo.novell.com |
Reporter | manfred.h@gmx.net |
QA Contact | qa-bugs@suse.de |
Found By | --- |
Blocker | --- |
This has some history. For some time, "use_lvmetad = 1" in /etc/lvm/lvm.conf used to work. With some update this got reset to "0" by default. While the system used to work, it became apparent that running "dracut" (former "mkinitrd") now takes appr. 1 minute per installed kernel. Also, running "lvs" almost takes forever... When I compared my Tumbleweed installation with my other Leap installations, I found out that on Leap "lvmetad" is running, resulting in snappy responses after "lvs" commands, and also pretty fast "dracut" runs. OK, let's activate "lvmetad" in Tumbleweed. First I activated/enabled and started "lvm2-lvmetad.socket", followed by stopping a potentially running (but there was't any) "lvm2-lvmetad.service". I then set "use_lvmetad = 1" in /etc/lvm/lvm.conf, started and enabled "lvm2-lvmetad.service" and rebuilt the initrd. The following reboot then got hung at "Waiting for /dev/mapper/rdisk00-swapdev1 to appear" and a similar message for the corresponding LV for /var. My setup is using /dev/md0 (MD-raid10) as a physical volume, providing space for such volumes as /var, /swapdev1 and /home. It is my understanding that at some point "/usr/lib/udev/rules.d/69-dm-lvm-metad.rules" should run "pvscan --cache" to provide the necessary udev events feeding into dm/udev to actually activate volumes, but, apparently this doesn't happen. Whe I got stuck in the single-boot/rescue phase after the boot, running "pvscan --cache" manually, followed by a "udevadm trigger" made the missing VG and LVs available; but, since /var is on an LV, the system is not actually usable at that point in time. I then downgraded the "lvm2" package (from "2.02.141-64.2" in current TW) to "2.02.120-67.1" to Leap's most current version, repeated all the lvmetad related configs from above, rebuilt the initrd, rebooted and - voila - my system boots again - and running "dracut" is not at all that boring again (appr. 10 secs. per kernel now). It looks to me that the current LVM2 package is not lvmetad capable.