Tag Info

New answers tagged

1

You screwed up. You were told you couldn't format the disk because it was in use. It was in use. You were trying to format one of the existing disks, not the new one. Now you formatted the existing drive and lost your data. You will need to restore from backup. You can see from the pvdisplay output that /dev/sdd1 is 100% free, so that seems to be the ...


1

Looks like multipath on the Hypervisor refuses to update its maps for LUN sizes. This LUN was originally 28Gb and was later grown to 48Gb on the storage array. The VG information thinks its 48G and indeed this disc is 48G, but multipath won't update and thinks it's still 28G. Multipath clinging to 28G: # multipath -l 350002acf962421ba 350002acf962421ba ...


1

See devices.txt in the kernel documentation: Major 202 is "Xen Virtual Block Device", major 253 is LVM / device mapper. All your dm-x devices are 253:n; they just point to 202:n. The error message is clear: device-mapper: table: 253:7: xvdb too small for target: start=58714112, len=41943040, dev_size=58720256 It seems there has been a change to the XEN ...


0

Thanks Psusi This would have been far easier than what I did in the end. I used testdisk with a deep analysis to re-rediscover the underlying partition. This took a few hours as it was a 89% full 2TB drive. Once I had found the drive and its dimension (automatically by testdisk), I wrote the changes. One caveat though is to select intel as the partition ...


1

Since physical and logical volumes can't span different volume groups, the volume group becomes important when you want to take if offline or move it between different systems. The volume group is another way of subdividing and managing resources.


2

Volume Groups have their uses; they keep PV separate, so things don't mix where they shouldn't be mixed. For example adding an external disk to your internal VG may be a bad idea since LVM does not particularly like missing disks. You could just as well argue that a single partition or single filesystem was enough. Why use several LV when one is enough to ...


2

Another way to see the logical extent allocation by physical device is to use: lvdisplay --all --maps If you wish to limit the query to a particular volume group, simply add it as an argument.


3

To show all lvs and where they come from you can check with: lvs -ao +devices


1

I did this same thing myself the other night while debugging gparted. I used dd if=/dev/zero count=1 of=/dev/sdc to wipe out the dos partition table, then pvcreate --uuid xxxx --norestorefile to reinitialize the lvm header, and finally vcfgrestore to restore from the backup in /etc/lvm/backup, which you can also look at to find what the uuid of the drive ...


3

If you look in /etc/lvm/lvm.conf, there is a devices { ... } section. You probably need to adjust the filter to accept /dev/mapper/root as a valid location. The easiest filter would be to accept all devices: filter = [ "a/.*/" ]. You could also accept only the device you're interested in: filter = [ "a|^/dev/mapper/root$|", "r/.*/" ]. Your initramfs ...



Top 50 recent answers are included