Bug 195476 - [RHEL4 U4 beta] anaconda stalls when executes 'lvm vgchange -ay' if the system has some mirror LVs in one VG. (Regression)
[RHEL4 U4 beta] anaconda stalls when executes 'lvm vgchange -ay' if the syste...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Alasdair Kergon
: Regression
Depends On: 193604
Blocks: 181411
  Show dependency treegraph
 
Reported: 2006-06-15 09:23 EDT by Jeff Layton
Modified: 2014-06-18 03:35 EDT (History)
9 users (show)

See Also:
Fixed In Version: RHBA-2006-0504
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:49:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
proposed patch (1.99 KB, patch)
2006-06-15 10:34 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Comment 1 Jeff Layton 2006-06-15 09:27:59 EDT
To summarize:

Whether Jonathan's patch goes in or not, we'll end up with the event monitoring
daemon not getting started at boot time. So we need to activate it later
(sometime after /usr is mounted). This BZ is opened to make that happen.

Since we're doing that, I'll also change the lvm.static vgchange to prevent it
from trying to start the monitoring too and circumvent the error messages.
Comment 2 Bill Nottingham 2006-06-15 10:16:17 EDT
Wait, why is the command *now* starting a daemon on LVM activation?

That should be done either a) via udev rules or b) via a separate initscript. I
don't see how --monitor yes should ever be the default.
Comment 3 Jeff Layton 2006-06-15 10:34:35 EDT
Created attachment 130978 [details]
proposed patch

This patch adds "--monitor n" to the initscripts, though Bill's suggestion to
make that the default may be a better way to go.

...actually, I seem to now be getting different results when using "--monitor
n". After a fresh reboot, with this patch:

[root@x330-2 ~]# vgchange -an
  testvg-lv1: event deregistration failed: No such device
  testvg-lv2: event deregistration failed: No such device
  0 logical volume(s) in volume group "testvg" now active
[root@x330-2 ~]# vgchange -an --monitor n
  0 logical volume(s) in volume group "testvg" now active
[root@x330-2 ~]# vgchange --monitor n
[root@x330-2 ~]# vgchange -ay
[root@x330-2 ~]# lvm.static vgchange -ay --monitor n
  2 logical volume(s) in volume group "testvg" now active
[root@x330-2 ~]# lvm.static vgchange -ay --monitor n
  testvg-lv1: event deregistration failed: No such device
  Failed to unregister logical volume, lv1
<hang here>

So now I'm not so sure that "--monitor n" is actually helping here.
Comment 4 Jonathan Earl Brassow 2006-06-15 16:45:39 EDT
Firstly, when the dmeventd patch goes in, it should _not_ hang.  At which point,
this may turn into an LVM bug.  It is confusing whether the '--monitor n' in the
last two commands means "don't perform any monitoring ops" or "unmonitor all
devices".  Seems to me it is the latter.

The '[root@x330-2 ~]# vgchange -ay' loaded and monitored the devices.
The following '[root@x330-2 ~]# lvm.static vgchange -ay --monitor n' are
unmonitorring them...

I'll test this more and see what bugs exist with the upcomming code.
Comment 8 Alasdair Kergon 2006-07-04 16:27:37 EDT
Some fixes and workarounds added to 2.02.06-4.0 to address several of the
problems mentioned on this bug.
Comment 11 Red Hat Bugzilla 2006-08-10 17:49:56 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0504.html

Note You need to log in before you can comment on or make changes to this bug.