Bug 207204 - pvmove hangs when tried from rescue disk context
pvmove hangs when tried from rescue disk context
Status: CLOSED DUPLICATE of bug 213887
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jonathan Earl Brassow
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-19 17:39 EDT by Jonathan Earl Brassow
Modified: 2007-12-04 16:37 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-27 12:40:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
typescript of events (8.59 KB, text/plain)
2006-09-19 17:42 EDT, Jonathan Earl Brassow
no flags Details
typescript of the pvmove when in the normal system (10.55 KB, text/plain)
2006-09-19 17:57 EDT, Patrick C. F. Ernzer
no flags Details
the kernel oops I captured on the serial console (2.09 KB, text/plain)
2006-09-19 17:58 EDT, Patrick C. F. Ernzer
no flags Details
the Oops described in Comment #5 (30.25 KB, text/plain)
2006-09-19 19:07 EDT, Patrick C. F. Ernzer
no flags Details
he Oops described in Comment #7 (18.16 KB, text/plain)
2006-09-19 19:11 EDT, Patrick C. F. Ernzer
no flags Details

  None (edit)
Description Jonathan Earl Brassow 2006-09-19 17:39:24 EDT
Patrick has encountered a bug where pvmove hangs the machine when run from a
rescue environment.  I've been unable to reproduce this bug on my own outside
that environment (in normal boot-up).

I will attach a file that is a typescript of what he was trying to do...

Essentially, user was trying to pvmove contents off of one disk and onto another
to eventually remove that disk.  One of the LVs being moved was fragmented (4
times?).  It appears that when pvmove got to the end of one of those fragments,
it would hang.  (You can see this from the first two 'dmsetup table' outputs.) 
The user would issue a ^c on the pvmove, then issue the command again, and it
would proceed to the next segment.  (You can see this from the 3rd 'dmsetup table')

This is my best guess at the problem.  Not sure if it is reproducible.
Comment 1 Jonathan Earl Brassow 2006-09-19 17:42:47 EDT
Created attachment 136680 [details]
typescript of events
Comment 2 Patrick C. F. Ernzer 2006-09-19 17:55:42 EDT
booted into normal install (fully updated RHEL4) after that (move of the LV with
/ had finished).

  pvmove -t -v -n /dev/Volume00/LogVol_amanda_hold /dev/sdd1 /dev/sda3
went fine

  pvmove -v /dev/sdd1 /dev/sda3
hung

typescript and kernel panic will follow.
Comment 3 Patrick C. F. Ernzer 2006-09-19 17:57:23 EDT
Created attachment 136682 [details]
typescript of the pvmove when in the normal system
Comment 4 Patrick C. F. Ernzer 2006-09-19 17:58:42 EDT
Created attachment 136683 [details]
the kernel oops I captured on the serial console
Comment 5 Patrick C. F. Ernzer 2006-09-19 19:05:17 EDT
the sage continues, after the Oops in Comment #2 I hit reset thinking "ah well,
I'll move the LVs one by one then".
Oops on boot, console log will follow.
Comment 6 Patrick C. F. Ernzer 2006-09-19 19:07:02 EDT
Created attachment 136688 [details]
the Oops described in Comment #5
Comment 7 Patrick C. F. Ernzer 2006-09-19 19:09:21 EDT
and the saga continues further.
At the stage of Comment #5 I figured "oh well, recue mode then, I want to go
home, it's past 1am and I stll have not had dinner", so boot ino rescue, choose
to mount partitions r/w when anaconda asks. You guessed it, Oops again.
Comment 8 Patrick C. F. Ernzer 2006-09-19 19:11:06 EDT
Created attachment 136689 [details]
he Oops described in Comment #7
Comment 9 Patrick C. F. Ernzer 2006-09-19 19:15:46 EDT
and just tom complete the saga, booted rescue but chose not to mount, "lvm
pvmove --abort" rebooted back to normql system, did the pvmoves one LV at a
time. All seems good now.
Comment 10 Jonathan Earl Brassow 2006-09-20 10:41:27 EDT
Looking at the attachment in comment #3...

When the logical volume is not specified, and pvmove is run, I find it strange
that a 'pvmove0' is reported for each of the 3 LVs being moved.  I'm not sure
what that means yet...
Comment 11 Jonathan Earl Brassow 2006-09-20 10:43:26 EDT
... and why do I see messages like 'Volume00/pvmove0 already monitored.'  pvmove
devices should _NEVER_ be monitored.
Comment 12 Jonathan Earl Brassow 2006-09-20 10:46:10 EDT
no doubt, the panics are happening due to a check-for-sync off the end of a bitmap.
Comment 13 Jonathan Earl Brassow 2006-10-17 10:54:51 EDT
I've added code to ensure that PVMOVE volumes are never monitored.  I'm not 100%
sure that the panic has been fixed, however.

It would be nice if this could be run again with the updated packages...
Comment 15 Jonathan Earl Brassow 2006-11-13 18:00:05 EST
this bug has been reproduced (pretty sure) and is bug #213887
Comment 17 Corey Marthaler 2007-01-24 16:19:52 EST
based on comment #15, I'm moving this back to assigned.

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