[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] Rezising root ("/") partition



Keywords to this subject: Linux LVM , root ( / ) partition / directory / filesystem rezize , vgreduce problem , filesystem / superblock info size greater than VG size , fsck , etc.


Hello guys,


I just would like write down the expirience I had yesterday, actually it spent the whole night, trying to resize a main file server root partition.

Our server runs a RedHat Linux 9.
My main difficulty was to umount the / partition in order to resize its filesystem. So I used the shell from the installation CD. I did the whole steps using that CD shell: create a new partition PV (I did not rebooted after this! Maybe it was the great fault), extended the VG, exnteded the LV and resized the filesystem. Then, I mounted the / partiton, executed a "df" which showed the new size of the / filesystem. So I rebooted the system, without the CD. And the nthe terrifying error: "the superblock says that the / filesystem has NEW_BIG_SIZE blocks, but the it only has OLD_SMALL_SIZE physical blocks. The partition table or the superblock information is wrong. run fsck to correct the error...".
So I gave the root password and tried to see what's happened. After all I found out that the new PV was contained in the root VG, the root VG had the new big size, the filesystem also had the new size, but if I remembered it right, the root LV was with the old small size and also the "allocable(?, or something like)" size of the root VG was the old small one. I could not resize the root filesystem and the root LV again and I could not remove the new PV from the root VG either. I tried to do "pvmove", etc, I just could do anything, and every scan and display said the thaere was no inconsistency. I knew about vgcfgrestore, but I was not able to make it work correctly.


Any way, let me try to try explain my solution too. 2 threads that helped me to figured out:

Fixing a VG with an empty borked PV
 http://lists.sistina.com/pipermail/lvm-devel/2003-March/001195.html

Help! unable to mount lv's - can't see why!
 http://lists.sistina.com/pipermail/linux-lvm/2002-September/012263.html

Using the rescue from the installtion CD, I had the thought to rollback what I have done, but I just could not remove the dammed new PV from the root VG. After a long time (I started all this at 7:00h PM of 2003-11-20, it was already 2:00 AM of 2003-11-21 and just finished all this at 4:15 AM of 2003-11-21) and after I did a backup of all our changed data on thsi server, I could try to do some operations not being so afraid. The root VG had already 2 partition PVs and I was trying to add another one. At some time, I was able to go vgcfgrestore of the root VG from /etc/lvmconf to the first 2 PVs. This backup was done automatically at some time before where the new PV was not contained the root VG. After the restore the root VG information show that the new PV was not in the root VG and the pvscan was saying that the new PV was in the root VG but it was INACTIVE: that was a good news for me. At this time I decided to delete that PV partition with fdisk, after thsi the root VG has gone in inconsistency, so I did the vgcfgrestore again to the first 2 PVs and the VG became consistent again, GREAT! After thsi I was able to do all the process again:

_ using the Rescue CD
_ create the new partition again using fdisk
_ pvcreate
_ vgextend
_ resize the LV and the filesystem with e2fsadm (without, ignoring fsck, which reports some inconsistencies due the superblock stuff...)


After this I did a vgcfgbackup and copied it to my real /etc/lvmconf. I also copied the file /etc/lvmtab.d/<ROOT_VG> to my rela /etc/lvmtab.d .

Here I leave a question: is this really necessary? It worked for me after this, but I do not know if the LVM information goes to the correct place, so that after booting without the Rescue CD it will be effective.

So, my last night and my sleeping hours were spent with this...

I hope this could help someone else.


Bye.



Hugo K.S. LPI ID: LPI000032731

--
-----------------------------------------------------------------------------
Hugo K. de Souza                Ícaro Technologies
Software Consultant             http://www.icaro.com.br
mailto:hugo icaro com br        Av. Barão de Itapura, 950, 8o andar, Botafogo
Work: +55 19 3237-7878 Ext: 248 Campinas, SP, Brazil
Fax: +55 19 3237-7008           CEP: 13020-431





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]