I have problems problems with moving the root filesystem from a PV on a partition to a PV on degraded mirror. When running "pvmove -v /dev/sda2 /dev/md1", it displays a few messages ending with Found volume group "VolGroup00" Loading VolGroup00-pvmove0 and the whole system is got stuck (I can type some characters, switch between consoles (Alt+Fx) and after (probably) trying to open a file (first I wanted to log in on other console, then I was opening a file in Midnight Commander) there is an end, no input possible) I found probably the same behaviour in a messages at http://www.redhat.com/archives/linux-lvm/2004-December/msg00007.html After powering the machine off and back on, the disks start working and after a while the move is completed. kernel-2.6.16-1.2111_FC4smp lvm2-2.01.08-2.1
I was moving 4 other LV (3 filesystems and 1 with swap) from the same PV too and there was no problem.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
I am not able to test the issue in current Fedora (or RHEL), so I am closing it.
Same problem in F10 yesterday. Two questions on this: 1) is moving the currently active rootfs even supposed to work? 2) could it be that being more patient is required? Esp on 2), as I know that a pvmove will just continue after interruption and I wanted my box back ASAP yesterday, I just shrugged after 15 seconds of extreme sluggishness, reset the box, booted rescue to finish the pvmove and brough the box back up. If you can confirm that the answr to both is yes I can retest (on different hardware though) and just let it run overnight. And I may be able to retest on the same hardware but in a different direction (had to move my LVs temporarily off the box, will move them back at some point)
Moving of rootfs should bacically work. But it can be problematic is some situations, the safest way it run the move from rescue disc, not from rootsystems itself. But maybe just new problem appeared, not too much info to check it here. (If you see that it stucks, we need at least output of "echo t >/proc/sysrq-trigger", "dmsetup status --noopencount" and ideally debug output of "pvmove -vvvv <params>" to see whats' happening.) Anyway, there were some reports of pvmove speed problems, not sure it this is the problem here. Btw 15 seconds is default check interval (see -i option), pvmove basically just monitors progress and in specified time intervals update metadata mappings, the real transfer run in kernel.
for the record: 471042 is the cluster pvmove regression
doh! it just dawned on me that the PV I moved the data from also had the LV for swap on it. Could that have been the problem? Did another pvmove (back from the external temporary disk to the internal drives), but disabled swap (swapoff -a, I have 8GB RAM on this box, so it's no problem to swith the 2GB swapp off temporarily) and that went just fine.
I have just successfully moved my / to another PV. It was done from runlevel 1 and all other filesystems were unmounted, swap was enabled. lvm2-2.02.39-7.fc10.x86_64 kernel-2.6.27.12-170.2.5.fc10.x86_64
Dan, did you only move the LV / or a whole PV that contained / and swap? In case of the latter I think we can close this (bug owner will decide), in case of the former we may want to just make a note in the man page to not move the swap LV
I moved all LVs stored on the PV manually (including the swap) with "pvmove -n <name-of-lv> /dev/source /dev/destination", only the "/" was moved in runlevel 1.
Please, anyone who can reproduce this bug, try it and when the computer locks up, press Alt+SysRq+W. Copy the result and paste it here.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.