0

I was trying to leave more available space at /datos and I break the configuration of my server.

  • First at all I discovered a LVM configuration.

  • Then at VMWARE client I click edit settings and add 50GB to the virtual disk.

  • Then pvresize 300G /dev/sda2 the only PV, that belongs to vg_admision1vm

  # pvdisplay

  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               vg_admision1vm
  PV Size               249.51 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              63874
  Free PE               0
  Allocated PE          63874
  PV UUID               dQO15U-Zyhb-LSSY-P7do-BXnj-3PC5-E127UE

  # pvresize --setphysicalvolumesize 300G /dev/sda

  WARNING: /dev/sda2: Overriding real size. You could lose data.
  Physical volume "/dev/sda2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized


  # pvdisplay 

  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               vg_admision1vm
  PV Size               300.00 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              76799
  Free PE               12925
  Allocated PE          63874
  PV UUID               dQO15U-Zyhb-LSSY-P7do-BXnj-3PC5-E127UE
  • An finally, I executed for extend a logical volume on vg_admision1vm.
 # lvextend -L+30G /dev/mapper/vg_admision1vm-LogVol04 
  Size of logical volume vg_admision1vm/LogVol04 changed from 140.38 GiB (35938 extents) to 170.38 GiB (43618 extents).
  device-mapper: resume ioctl on  failed: Invalid argument
  Unable to resume vg_admision1vm-LogVol04 (253:2)
  Problem reactivating LogVol04
  Releasing activation in critical section.
  libdevmapper exiting with 1 device(s) still suspended.
  • After that error I read that when resizing a LV ones must to resize fs. But I didn't that. After that any lv command hang out then I reboot machine and in boot time I get:
/dev/mapper/vg_admision1vm-LogVol04 is mounted.
e2fsck: Cannot continue, aborting.
  • I think that to resize back LogVol04 is a good idea, because my understanding says that the device mapper cannot create device /dev/mapper/vg_admision1vm-LogVol04 because filesystem and logicalvolume have different size. How to resize again vg_admision1vm-LogVol04 to reduce 30GB?

  • I also think that is possible in certain way to configure correctly the device mapper using dmsetup.

  • /dev/mapper/vg_admision1vm-LogVol04 used to be mounted at /datos.

  • At vg_admision1vm belongs more logical volumes but apparently are not affected.

  • A don't know how works but I note that the table for logVOl04 is empty, maybe to define a table could work, but I don'y know how to define a table given a logicalvolume.

  • Also I tried this, and I note this strange state:

    # umount /datos
    unmount: /datos: not mounted
    # mount -t ext4 /dev/sda2 /datos
    /dev/sda2 already mounted or /datos busy
    mount: according to mtab, /dev/mapper/vg_admision1vm-LogVol04 is already mounted on /datos
    
2

I think the following is the answer:

pvresize --setphysicalvolumesize 300G /dev/sda

WARNING: /dev/sda2: Overriding real size. You could lose data.

You should have resized the patition before resizing the PV. Now you have 300GB PV on 250GB partition. I am surprised this is allowed without --force option.

Luckily you have not extended the FS. The LV is not usable at the moment - it can not be activated and remains suspended:

device-mapper: resume ioctl on failed: Invalid argument Unable to resume vg_admision1vm-LogVol04 (253:2) Problem reactivating LogVol04 Releasing activation in critical section. libdevmapper exiting with 1 device(s) still suspended.

Reducing the LV works well for me: just run lvresize -L-30G /dev/vg_admision1vm/LogVol04 answer yes to the scary question and the device will be resumed.

Now you should either extend the partition (which may not be possible while the device is using it) or reduce the PV and start again.

There are tons of tutorials how to resize partition. This is a little bit error prone process. You better have a backup. Using fdisk you need to delete the partition and then recreate it with larget size. (g)parted does this in background for you.

One advice: Never run fsck on broken devices. Try first recovering data, in this case missing blocks. Running fsck on filesystem with missing parts will ruin it.

Fortunately nothing could have been written there so you should have no data corruption.

Second advice: Have a look at lsblk and lsblk -s output. When extending you start at the "bottom": disk, [partition], [LUKS], PV, LV, FS. When reducing you need to start at the top, first reducing filesystem, then the device right under the FS, etc.

Here you extended the disk, so first should have extended the partition, then the PV. This would have resulted in free space in the VG so you would be able to resize the LV and then the FS.

0

I face a similar problem today. I don't remember why I use the pvresize --setphysicalvolumesize command a long time ago, but it was a bad idea.

Extended the hard drive then pvresize /dev/sdnX should do the job without indicate any size.

My solution was booting a live distro, to extend the partition of the PV /dev/sdnX with fdisk, deleting the partition then recreated with more sectors, (reboot if necessary) then pvresize /dev/sdnX. As suggested by Martian, parted do the job for you.

resize2fs the LV, run a filesystem check (e2fsck -f /dev/sdnX) then mount it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.