[linux-lvm] lvrename oddities

[Peter.Wuestefeld at resnova.de]

Hi all,

seen this already?

Systems:
2x PII/450MHz, 1G RAM, Vortex GDT RAID w/ 70G, 3c905TX, installed: SuSE 
6.4, LVM 0.8e (4/1/2000), compiled at SuSE from lvm-0.8-41.src.rpm
Dell Inspiron 7500, PIII mobile 650/500Mhz, 256M RAM, 18G, installed: SuSE 
6.4, LVM 0.8e (4/1/2000), compiled at SuSE from lvm-0.8-41.src.rpm

Actions:
umount /dev/datavg/usrnewlv
lvchange -a n /dev/datavg/usernewlv
lvrename /dev/datavg/usrnewlv /dev/datavg/usrlv
lvchange -a y /dev/datavg/usrlv
mount /dev/datavg/usrlv

Thus far everything worked o.k.
reboot:
vgscan didn't find any VGs, as a follow-on the systems came up without any 
mounted LVs (of course!)
no /etc/lvmtab, no /etc/lvmtab.d

Solution:
- vgchange -a n datavg
- mkdir /etc/lvmtab.d
- cp -p /etc/lvmconf/datavg.conf.1.old  /etc/lvmtab.d/datavg
- cp -p /etc/lvmconf/datavg.conf.1.old /etc/lvmtab
- vgcfgrestore -f /etc/lvmconf/datavg.conf.1.old -n datavg /dev/hda4
- vgchange -a y datavg (Yuppie! success!)
- mount -a 

Just worked because the root FS was on a non-LVM partition.

The old name was restored and the LV could be used again (no data was 
lost). Since that happened on the SMP production system I didn't bother 
playing around and tested on my notebook instead. Not only could I easily 
reproduce the problem,  I also got an  idea what went wrong.

The problem seems to be related to the lvchange -a y after renaming the 
LV. At least it is this what I can conclude after testing.

- lvrename without lvchange -a y did no harm; the machine rebooted 
happily.
- lvrename with lvchange worked as long as the machine was running. The FS 
could be mounted and worked on. On reboot, no /etc/lvmtab and 
/etc/lvmtab.d existed and led to the problems described above. 
- after trying the trick two times on the same LV, on shutdown a lot of 
nasty messages looped very fast (I added -v -d to vgchange in the shutdown 
script); what I could decipher were snippets like ' -322"'and ' vgname "" 
'. I had to switch off the box in order to reboot.
- on boot, vgchange was able to detect the VG and activate it. Luckily the 
recovery procedure described above worked reliably every time I used it - 
since the config files below /etc/lvmconf get rotated every time when 
there have been changes. I copied a working datavg.conf to a safe place 
and used that instead.
- trying to rename the LV again led to the situation that it could be made 
active but booting was even worse; although the VG was activated, no FS 
could be mounted (".../datavg/nnlv is not a valid block device"); in fact, 
I had to delete the LV since I couldn't get it correctly running again. It 
looks like that recovering from renaming can be done only once on a LV. 
Every time after that the LV was "NOT available" after reboot. lvchange -a 
y worked but led to the known problem.

To me it seems as if lvchange is not working correctly after an lvrename, 
rendering the config files useless. When booting, vgscan wipes out 
/etc/lvmtab.d and its contents as well as /etc/lvmtab. On creating the new 
files it stumbles over the corrupted data in /etc/lvmconf/datavg.conf and 
is unable to (re-)store them correctly.

What I'm trying to find out is if this issue is only related to SuSE 6.4 
since I seem to recall that I had that problem on a Debian 2.1 
distribution at least a year ago as well.

Since I was not able to find this issue in the list archives and I don't 
want to patch and recompile the kernel for each and every box I administer 
(there are quite a few out there now; OS migrations are also to consider 
which would lead to additional hassle in this respect as well) - what is 
the recommended solution for this problem?

Can somebody please shed some light on me?

Thanks,

Peter

Mit freundlichem Gruss/Best Regards

Peter Wuestefeld
==================================
res nova Unternehmensberatung GmbH
                   ...aktiv in AIX
MAIL:  Ruppmannstrasse 41
       D-70565 Stuttgart, Germany
FON:   +49 711 78888 0
FAX:   +49 711 78888 99
WWW:   http://www.resnova.de
SMTP: mailto: Peter.Wuestefeld at resnova.de

Computers are useless. They can only give you answers.
        -- Pablo Picasso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20000803/4e3ed955/attachment.htm>