RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 813766 - Do not try to use lvmetad during early system init stage
Summary: Do not try to use lvmetad during early system init stage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.3
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: 6.4
Assignee: Petr Rockai
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 817776
TreeView+ depends on / blocked
 
Reported: 2012-04-18 11:49 UTC by Peter Rajnoha
Modified: 2013-02-21 08:09 UTC (History)
10 users (show)

Fixed In Version: lvm2-2.02.98-1.el6
Doc Type: Bug Fix
Doc Text:
The LVM tools were printing spurious warning during bootup, if use_lvmetad = 1 was set in lvm.conf. This has been fixed.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:09:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
lvmetad_warn.diff (1.90 KB, patch)
2012-10-12 00:51 UTC, Petr Rockai 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0501 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2013-02-20 21:30:45 UTC

Description Peter Rajnoha 2012-04-18 11:49:07 UTC 
Description of problem:
We should not try to use lvmetad before the lvmetad daemon is run by lvm2-lvmetad init script while having global/use_lvmetad=1 set in lvm.conf. Otherwise any LVM command run before the lvm2-lvmetad init script will issue a warning message that could cause a user to think that something wrong is going on:

"WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to internal scanning."

This is the case with the rc.sysinit script that calls the "vgchange -ay" command to activate existing VGs.

Suggestions and possible solutions:

 A. That vgchange in rc.sysinit uses the "--sysinit" switch so we could probably disable lvmetad use in this case. This would *work only* with lvchange and vgchange as --sysinit is defined only for these commands. Also, the "lvmetad_init" fn that causes the warning message to appear is called before the lvm command arguments are fully initialized and processed. So it's not that straightforward.

 B. Just use "vgchange -ay --config 'global{use_lvmetad=0}' ..." (so a change for the "initscripts" package)

 C. Or this bug will get obsolete as we'll switch to using on-the-fly udev-event-based VG/LV activation as PVs appear in the system (as we have the information collected and stored by the lvmetad itself now) and so we can remove the "vgchange -ay" call in the rc.sysinit, lvmetad will take care of any activation. But what if lvmetad is disabled???

This needs some thought and discussion...

(This problem appears even sooner during dracut stage, but that was resolved by using method B as dracut already changes the system-wide lvm.conf settings to better suit the initramfs, filed as bug #811129.)
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
Note You need to log in before you can comment on or make changes to this bug.