|Summary:||Do not try to use lvmetad during early system init stage|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Peter Rajnoha <prajnoha>|
|Component:||lvm2||Assignee:||Petr Rockai <prockai>|
|Status:||CLOSED ERRATA||QA Contact:||Cluster QE <mspqa-list>|
|Version:||6.3||CC:||agk, dwysocha, heinzm, jbrassow, msnitzer, nperic, prajnoha, prockai, thornber, zkabelac|
|Fixed In Version:||lvm2-2.02.98-1.el6||Doc Type:||Bug Fix|
The LVM tools were printing spurious warning during bootup, if use_lvmetad = 1 was set in lvm.conf. This has been fixed.
|Last Closed:||2013-02-21 08:09:19 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Peter Rajnoha 2012-04-18 11:49:07 UTC
Comment 2 Petr Rockai 2012-07-01 09:59:16 UTC
I vote for A) here. I'll look into it.
Comment 3 Peter Rajnoha 2012-07-02 10:35:48 UTC
Well, actually, we can't rely on the --sysinit arg. The "vgchange --sysinit" call will stay for current RHEL, but not for RHEL7 and recent Feodras (F17+) as that will become just a simple "vgchange" without --sysinit (/run is available soon in the boot process and is writeable so no need to use sysinit anymore in the script, bug #742564, I'm just about to ping Bill to change this). So maybe B is more appropriate (or whatever else that will do the job).
Comment 4 Alasdair Kergon 2012-07-02 10:57:50 UTC
--sysinit exists to avoid the need for --config overrides. If we need two different behaviours of --sysinit, then introduce another --sysinit arg to distinguish them?
Comment 5 Peter Rajnoha 2012-07-02 12:05:57 UTC
Hmm... thinking of it more, maybe it's not needed at all! For RHEL6, we keep the --sysinit in rc.sysinit and we could add the "ignorelvmetadfailure" case to it as already suggested in A (which would also work for dracut then). And for RHEL7+Fedora with systemd, the lvmetad daemon is started automatically by systemd on the first socket access. And all the sockets are available as the very first thing during boot in systemd environment... So, I think we could just remove the --sysinit from the new fedora-storage-init script (which has the vgchange the former rc.sysinit called) as everything should be available and/or autostarted there. So the A might probably work just fine... OK.
Comment 6 Petr Rockai 2012-10-12 00:51:00 UTC
Created attachment 625741 [details] lvmetad_warn.diff If I understand correctly, the desired behaviour is to just suppress the warning about being unable to contact lvmetad if --sysinit is given. The attached patch implements that. Can be pulled as 35e02fe2d6fb50f2facfbe2dc6422fdc669b03c7 from http://repos.mornfall.net/lvm2/mornfall.git/ if this is indeed the desired fix.
Comment 7 Petr Rockai 2012-10-12 09:01:27 UTC
Pushed as 28776b9526784fc3dd2ab94a4151613771c4dfda. To verify, check that, with use_lvmetad = 1 in lvm.conf: 1) lvm commands do not print "WARNING: Failed to connect to lvmetad..." on bootup 2) lvm commands print a WARNING during normal system use when lvmetad is not running
Comment 9 Nenad Peric 2013-01-24 16:39:48 UTC
(10:37:10) [root@r6-node01:~]$ lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert lv_root VolGroup -wi-ao--- 7.54g lv_swap VolGroup -wi-ao--- 1.97g auto_lv vg -wi-a---- 20.00m (10:37:18) [root@r6-node01:~]$ service lvm2-lvmetad stop [ OK ]g LVM metadata daemon to exit: [ OK ] (10:37:25) [root@r6-node01:~]$ lvs WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to internal scanning. LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert lv_root VolGroup -wi-ao--- 7.54g lv_swap VolGroup -wi-ao--- 1.97g auto_lv vg -wi-a---- 20.00m (10:37:26) [root@r6-node01:~]$ No warning was displayed during the boot up sequence. Tested with: lvm2-2.02.98-9.el6.x86_64
Comment 10 errata-xmlrpc 2013-02-21 08:09:19 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0501.html