Due to a series of mistakes i resized my drive to be smaller than the physical volume it contains. The drive has a physical volume at around 110Gib, a logical volume at 100Gib, all on a 99.4Gib drive. The actual data on the logical volume is only 50gb or so, but i cant resize anything because i cant mount anything due to this mishap and i need the data off the logical volume. Output of

:

WARNING: Device /dev/sda3 has size of 208445799 sectors which is smaller than corresponding PV size of 230684672 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG ubuntu-vg have changed sizes.
LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi------- 100.00g

Output of

:

WARNING: Device /dev/sda3 has size of 208445799 sectors which is smaller than corresponding PV size of 230684672 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG ubuntu-vg have changed sizes.
PV         VG        Fmt  Attr PSize    PFree
/dev/sda3  ubuntu-vg lvm2 a--  <110.00g <10.00g

Output of

:

WARNING: Device /dev/sda3 has size of 208445799 sectors which is smaller than corresponding PV size of 230684672 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG ubuntu-vg have changed sizes.
VG        #PV #LV #SN Attr   VSize    VFree
ubuntu-vg   1   1   0 wz--n- <110.00g <10.00g

I run a bare metal Ubuntu server with several VMs running in a KVM environment. I want to increase the size of one VM from 50GB to 100GB. I ran the following command to increase the nextcloudph-lv VM from 50GB to 100GB:

lvextend -L+50G /dev/ubuntu-vg/nextcloudph-lv

The VM size increased as expected. I then attempted to extend the LV file system using the following command:

resize2fs  /dev/ubuntu-vg/nextcloudph-lv

The output I received is: Running the lsblk command results in: And /dev/mapper contains: This looks like a relatively simple process so I'm not sure where I've gone wrong. This is the first time I'm trying to extend an LV and I'm stuck... Thanks in advance! EDIT: As suggested by A. Darwin, I ran the command "df -hT" which produced the following output: I can see the host VM "ubuntu--lv" with an ext4 file system but there is no reference to "nextcloudph--lv" or sda3 where all the VMs are located. I'm not sure if it makes a difference but when I set up the VMs I first allocated the space using the "lvcreate -L ##G -n lv###### ubuntu-vg" command and then pointed Virtual Machine Manager to that storage pool when building the VM. EDIT 2 Running "df hT" from within the nextcloudph-lv VM produces the following output: It's strange because there is a reference to a 48GB ext4 drive but it's located at "/dev/mapper/ubuntu--vg-ubuntu--lv". EDIT 3 As requested by Vojtech Trefny, attached is the output from the command "lsblk -f" For clarity, the 84% used refers only to the ubuntu--lv VM. There is still plenty of room left on the SSDs.

I have the following LVM partition: # df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/data-root 5.3G 4.2G 864M 84% / ... /dev/mapper/data-install 6.8G 5.7G 783M 89% /install # vgs VG #PV #LV #SN Attr VSize VFree data 1 2 0 wz--n- `. Also I would like to accomplish this using the command line alone (no GUI). It is also worth noting that the root/system logical volume is active and in use at all times.

Today, I rebooted my PC (a Dell G5 15) after a update from Ubuntu, you know, the kind of update that pops on the screen and asks you to reboot at the end to complete the update. Well, that’s what I did, and maybe I shouldn’t have. Now, I got this on my screen. (I have put red marks where I have executed the commands that were recommended above, for this thing to be a little clearer for you.) I don’t know what my latest version of Ubuntu that worked was. I tried to search for similar problems, but I couldn’t find anything that helped me in my case. I tried to select the “Advanced option for Ubuntu” when I hard-restarted my computer, but among the possibilities below, none seems to work. How can I fix my computer?

i have a ~200GB luks encrypted partition on a dual boot setup and i've just shrunk my windows partition by a bit so i can use the unallocated space on my root partition which is xfs. how would i go about extending the luks partition and subsequently the voidvm/root one? $ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS nvme0n1 ├─nvme0n1p1 vfat FAT32 SYSTEM 089A-0EBD /boot/efi ├─nvme0n1p2 ├─nvme0n1p3 ntfs Windows 18E6E384E6E3610C ├─nvme0n1p4 ntfs 066C04116C03FA67 └─nvme0n1p5 crypto_LUKS 1 2ab65cad-808c-4168-8e51-0e081bd9d58b └─voidvm LVM2_member LVM2 001 c4mDao-UZLC-znl1-efSm-SmPB-DrRU-ChSQ82 ├─voidvm-root xfs root 2559b74d-53a8-437f-82e5-62b514f6987d 2.1G 91% / └─voidvm-home xfs home 60588d15-9846-43c9-996b-a4d09cea8b07 17.1G 90% /home Physical vol sudo pvs PV VG Fmt Attr PSize PFree /dev/mapper/voidvm voidvm lvm2 a-- <195.31g 0 LVM lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home voidvm -wi-ao---- <171.31g root voidvm -wi-ao---- 24.00g

I have a question regarding managing free or "unallocated" space in an LVM setup on CentOS. What i need to do is make /var bigger, to accommodate some additional VM's that i am creating. 1. I would need to claim some of that free space Edit #1: here is the output from fdisk /dev/sda. I don't have a complete understanding of the Start /End /Blocks, but being that as it is, I still don't see the free space that should be available [root@physical ~]# fdisk /dev/sda Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x0004cb56 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 448595967 223784960 8e Linux LVM /dev/sda3 448598016 546254265 48828125 83 Linux > Edit #2 OK so now I can see the space is there in parted! Wonderful and thank you!! Now my question is, what would I have to do to actually grab some of this space to use it? I am assuming whatever I grab, in my exact scenario would now be called ***/dev/sda4***. Would you be able to guide me on claiming 100GB from this free space? Thanks so much! [root@physical ~]# parted /dev/sda (parted) print free Model: ATA ST31000340NS (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 32.3kB 1049kB 1016kB Free Space 1 1049kB 525MB 524MB primary xfs boot 2 525MB 230GB 229GB primary lvm 230GB 230GB 1049kB Free Space 3 230GB 280GB 50.0GB primary 280GB 1000GB 721GB Free Space

Background ===== I'm running Centos 7. Originally, it was running on a single disk that looked something like this: 1 200M EFI System (/boot/efi) 2 500M Microsoft basic (/boot) 3 465.1G Linux LVM LVM VG centos - LVM LV ext4 centos-root (/) - LVM LV swap centos-swap (swap) This was just a temporary solution as it was originally supposed to be installed on a Linux software RAID1 array. I got around to migrating it today. This is what it currently looks like: Both new disks have this partition layout: 1 200M EFI System (/boot/efi) 2 457.6G Linux RAID /dev/md0 RAID1 (for boot and LVM) 3 8G Linux RAID /dev/md1 RAID0 (so 16GB total, for swap) /dev/md0 looks like this: 1 500M Linux filesystem (/boot) 2 457G Linux LVM (centos-root is migrated to this) LVM now has only one LV, centos-root /etc/mdadm.conf looks like this: ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=main.centos.local:0 UUID=5b5057b4:4235ba4b:5342dfda:acf63302 devices=/dev/sda2,/dev/sdb2 ARRAY /dev/md1 level=raid0 num-devices=2 metadata=1.2 name=main.centos.local:1 UUID=f82a8c99:9b391d83:4efc9456:9e9bad98 devices=/dev/sda3,/dev/sdb3 /etc/fstab looks like this: /dev/mapper/centos-root / xfs defaults 0 0 UUID=fcb5f82f-ce6b-460b-800f-329e010bc403 /boot xfs defaults 0 0 UUID=C532-14AE /boot/efi vfat umask=0077,shortname=winnt 0 0 /dev/md1 swap swap defaults 0 0 blkid outputs this (relevant entries only): /dev/sdb1: SEC_TYPE="msdos" UUID="C532-14AE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="ed301bbd-c15c-40af-ae75-bf238d0e6270" /dev/sda1: SEC_TYPE="msdos" UUID="C532-14AE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3a76412-41a0-4e04-9b04-ad1c159133cf" /dev/md0p1: LABEL="boot" UUID="fcb5f82f-ce6b-460b-800f-329e010bc403" TYPE="xfs" PARTLABEL="primary" PARTUUID="df8d6481-c6ce-423a-b5d5-205d355e5653" /dev/md0p2: UUID="7LfywM-oPHy-MTEt-swlI-EVbZ-opTo-m82E6R" TYPE="LVM2_member" PARTLABEL="primary" PARTUUID="19e7f9d5-a955-4036-8338-03a748faa1f6" /dev/mapper/centos-root: UUID="deaa9788-b487-4991-adf7-2945788fb6cd" TYPE="xfs" I have a script which automatically mounts the other EFI partition to /boot/efi_[device], and when the kernel is updated, the grub.cfg gets copied to this partition to keep everything in sync. /dev/sda1 and /dev/sdb1 are kept in sync by the script (I've verified this), so it shouldn't be an issue that fstab mounts either one to /boot/efi (this also means that if one drive was removed due to failure, the system is still guaranteed to boot). I could have put swap in a LV to simplify things, but the RAID0 gets better performance (for what it's worth) and I get an extra 16GB of space. I migrated the LV from the old drive to the new PV using the following commands: pvcreate /dev/md0p2 vgextend centos /dev/md0p2 pvmove /dev/sdg3 vgreduce centos /dev/sdg3 Then I regenerated the initramfs with dracut (after backing up the original), and finally regenerated grub.cfg. Afterwards, I mounted the new /boot and /boot/efi partitions and copied everything over. Problem ===== After disconnecting the old drive and booting, dracut fails to find my RAID arrays, and of course the /boot partition and my LVG as well. It appears that it's simply not calling mdadm --assemble on /dev/md0 and /dev/md. I'm able to do just that from the dracut prompt, after which lvm_scan finds my LVG, I can link /dev/centos/root to /dev/root, and the system continues booting without any problems once exiting the prompt. Everything seems to be exactly where it should be. There was a kernel update available, so I tried installing it (assuming I messed something up the first time around when regenerating the initramfs and grub.cfg files), but no dice. System still fails in the exact same way. This is true when I boot from either EFI partition manually (as it should be since the two are identical). Link to rdsosreport.txt on pastebin What am I missing here? How do I get dracut to assemble my arrays?

Is it possible to create a Logical Volume from more than one Volume Group... - ... if the Volume Groups reside on the same Physical Volume? - ... if the Volume Groups reside on different Physical Volumes? OS is RHEL 9.

I use LUKS (so my system is encrypted) and LVM. I don’t want sda displayed because that’s where my root filesystem lives, and it’s my root device. The solution should also work for systems without LUKS or LVM, meaning it must handle all scenarios. I'm on a Debian 12.x and I want to display all main devices in a one row command, if possible, ***except my root device***, regardless of whether it's an LVM, LUKS or not, etc. The command should be flexible, and I don’t want to use fixed specifications *--vg-root, etc., if possible. > **@bertieb comment:** From the added output, it seems the root mountpoint is in a volume group in an encrypted volume on the device is presenting itself as sda -- OP wants that entire device and all associated block 'devices' elided ? i.e. remove root vg AND swap, crypt, containing partition (sda3) plus other partitions, and finally the device (sda) And that should be my result, ***so all main devices without*** sda because that’s my root device where my root filesystem is /, and without me having to specify details, so I can use it on other **devices/systems** as well, whether LVM, LUKS, etc., without needing to know what root is called, or what the UUID is, etc. I don't want to see the partitions too, only the main devices without root device, like in this command lsblk -d -o NAME,SIZE --sort SIZE. This is the output I need: - No sda (since it's the root device containing my root filesystem /) - Only main devices displayed (regardless of how many exist) - No partitions included from the other devices ##### RESULT I NEED :

NAME     SIZE
nvme0n1  238.5G

**My Setup:**

$ lsblk -d -o NAME,SIZE --sort SIZE
NAME      SIZE
sda      57,3G
nvme0n1 238,5G

$ lsblk -fs -o NAME
# ROOT DEVICE
sda1
`-sda
sda2
`-sda
desktop--vg-root
`-sdb3_crypt
  `-sda3
    `-sda
...
...

$ lsblk
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                    8:0    1  57,3G  0 disk  
├─sda1                 8:1    1   512M  0 part  /boot/efi
├─sda2                 8:2    1   488M  0 part  /boot
└─sda3                 8:3    1  56,3G  0 part  
  └─sdb3_crypt       254:0    0  56,3G  0 crypt 
    ├─desktop--vg-root   254:1    0  55,3G  0 lvm   /
    └─desktop--vg-swap_1 254:2    0   980M  0 lvm   [SWAP]
nvme0n1              259:0    0 238,5G  0 disk  
└─nvme0n1p1          259:1    0 238,5G  0 part  /user/backup

I don't want that, for example /dev/mapper/desktop--vg-root,sdb3_crypt, sda3 no sda. But rather this here from the example sda, this is the root device, so I don't need this device in the output. #### MY DEVICES, MY SETUP:

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G    
`-nvme0n1p1    238.5G

**RESULT I NEED:**

NAME     SIZE
nvme0n1  238.5G

##### System setup Debian, lsblk and other information:

Operating System: Debian GNU/Linux 12 (bookworm)  
Kernel: Linux 6.1.0-22-amd64
Architecture: x86-64

lsblk from util-linux 2.38.1

$ apt-get install --only-upgrade util-linux

util-linux is already the newest version (2.38.1-5+deb12u3)

##### From @terdon RESULT:

(){ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF!="/"{printf "%-15s%-10s\n", $1,$2}'; }

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G    
`-nvme0n1p1    238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT

NAME                   SIZE MOUNTPOINT
sda                   57.3G 
|-sda1                 512M /boot/efi
|-sda2                 488M /boot
`-sda3                56.3G 
  `-sdb3_crypt        56.3G 
    |-desktop--vg-root    55.3G /
    `-desktop--vg-swap_1  980M [SWAP]
nvme0n1              238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF!="/"{printf "%-15s%-10s\n", $1,$2}';

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF=="/"' |-desktop--vg-root 55.3G / ##### From Chris Davies RESULT:

Root partition: mapper/desktop--vg-root
Root device: 
NAME      SIZE
sda      57.3G
nvme0n1 238.5G

##### From @muru: lsblk -d $(findmnt -no source /)

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
desktop--vg-root 254:1    0 55,3G  0 lvm  /

I found a similar question here, but there's one different point on my server: --- Volume group --- VG Name vg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size 465.50 GiB PE Size 32.00 MiB Total PE 14896 Alloc PE / Size 14896 / 465.50 GiB Free PE / Size 0 / 0 VG UUID xxxxx pvdisplay --- Physical volume --- PV Name /dev/sda3 VG Name vg PV Size 465.51 GiB / not usable 15.00 MiB Allocatable yes (but full) PE Size 32.00 MiB Total PE 14896 Free PE 0 Allocated PE 14896 PV UUID xxxxx I would like to install virtualizor on the server and using volume group storage configuration, but with this preinstalled OS configuration (volume group root) it is not possible and my skills are not enough to know how to do to shrink the volume group and create a new one.

Is it possible to pvcreate a pv by any more unique means than the standard "/dev/sdX"? The reason is the external multiple hard drive dock and dev mapper on my system don't always assign the same "/dev/sdX" at boot. I work around this with ext4 mounts in fstab by mounting by uuid, otherwise the results could be disastrous reads/writes to the wrong disk.

(I no longer have this setup so I cannot test new answers, sorry. I had to switch computers and am now only using arch; I am leaving the question as it is though since I'd love to know a solution if it occurs again, grub has been very hostile towards me these past few months) I have fedora 23 as my main OS with custom partitioning (all physical partitions) /boot/efi=/dev/sda1 root=/dev/sda3. Then on /dev/Sda2 I just set up an LVM physical partition, and created an LVM group (arch) and volume (root) and then I installed Arch Linux (without bootloader) on /dev/arch/root I have /dev/sda (GPT), /dev/sdb (GPT) then grub also seems to detect a hd2 and gives errors about being unable to load it (I assume this is the LVM physical partition) anyhow, I use os-prober and grub2-mkconfig to detect my arch installation, which it successfully does (and does so two times, I get two menu entries for it); but when I try to boot it I get the following errors: error: failure reading sector 0x0fc from 'hd2'. error: failure reading sector 0x0e0 from 'hd2'. error: failure reading sector 0x0 from 'hd2'. error: can't find command 'linux'. error: can't find command 'initrd'. I only get the sector reading errors on the first boot attempt (for the record, fsck reports the drive to be clean) any retries only give me the can't find command errors. This is the grub.conf menuentry: ### BEGIN /etc/grub.d/30_os-prober ### menuentry 'Arch (on /dev/mapper/arch-Root)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-38305dfb-279b-4490-948b-480b81fef81f' { insmod part_gpt insmod lvm insmod ext2 set root='lvmid/6ZmQFy-ijXr-mYra-3Gp9-l0dh-J4Wi-GSHXhd/WGN2VN-t34t-rYWi-kvje-2BfF-WoD4-4NinnP' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='lvmid/6ZmQFy-ijXr-mYra-3Gp9-l0dh-J4Wi-GSHXhd/WGN2VN-t34t-rYWi-kvje-2BfF-WoD4-4NinnP' 38305dfb-279b-4490-948b-480b81fef81f else search --no-floppy --fs-uuid --set=root 38305dfb-279b-4490-948b-480b81fef81f fi linux /boot/vmlinuz-linux root=UUID=38305dfb-279b-4490-948b-480b81fef81f rw quiet initrd /boot/initramfs-linux.img } Anyone got any ideas how to fix this? Any solution that will allow me to boot into arch (besides reinstalling the bootloader from arch instead of fedora) will be fine; I don't mind getting my hands dirty editing the grub.cfg file by hand.

I am having I/O errors on /dev/sda on a RHEL 9 server. Output of dmesg | grep sda: [ 3.323141] sd 0:0:0:0: [sda] 62914560 512-byte logical blocks: (32.2 GB/30.0 GiB) [ 3.323174] sd 0:0:0:0: [sda] Write Protect is off [ 3.323177] sd 0:0:0:0: [sda] Mode Sense: 3b 00 00 00 [ 3.323218] sd 0:0:0:0: [sda] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 3.327168] sda: sda1 sda2 sda3 [ 3.327468] sd 0:0:0:0: [sda] Attached SCSI disk [ 6.338087] XFS (sda2): Mounting V5 Filesystem fb24877b-278d-412a-8f68-e7f1909484b1 [ 6.390410] XFS (sda2): Ending clean mount [ 253.414807] sd 0:0:0:0: [sda] tag#58 task abort on host 0, 0000000030035026 [ 253.415338] sd 0:0:0:0: [sda] tag#58 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=180s [ 253.415342] sd 0:0:0:0: [sda] tag#58 CDB: Read(10) 28 00 01 ac b3 20 00 00 08 00 [ 253.415343] I/O error, dev sda, sector 28095264 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 However, this disk uses LVM. Should the fsck command be run on the underlying disk /dev/sda, or on the LVM partitions /dev/mapper/...?

I'm running Debian Wheezy (Linux wheezy3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux) as an encrypted LVM with hardware raid 1 (Adaptec 6405E) on a supermicro server. I was encounting the following errors during the the kernel update: Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64 update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64 error: unknown LVM metadata header. error: unknown LVM metadata header. Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.2.0-4-amd64 Found initrd image: /boot/initrd.img-3.2.0-4-amd64 error: unknown LVM metadata header. error: unknown LVM metadata header. error: unknown LVM metadata header. error: unknown LVM metadata header. Incorrect metadata area header checksum on /dev/sda1 at offset 4096 done Here is the output for pvdisplay, vgdisplay, lvdisplay, df, pvs, lvs, vgs: root@wheezy:~# pvdisplay -v Scanning for physical volume names Incorrect metadata area header checksum on /dev/sda1 at offset 4096 --- Physical volume --- PV Name /dev/dm-0 VG Name wheezy PV Size 111.37 GiB / not usable 2.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 28510 Free PE 0 Allocated PE 28510 PV UUID 8DEe3m-NaQC-mRia-cMfv-OO2O-Foog-XXTLeU "/dev/sda1" is a new physical volume of "243.00 MiB" --- NEW Physical volume --- PV Name /dev/sda1 VG Name PV Size 243.00 MiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID fnKsgr-KC2h-inYi-jhli-YFil-edTh-RsRTzK root@wheezy:~# vgdisplay -v Finding all volume groups Incorrect metadata area header checksum on /dev/sda1 at offset 4096 Finding volume group "wheezy" --- Volume group --- VG Name wheezy System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size 111.37 GiB PE Size 4.00 MiB Total PE 28510 Alloc PE / Size 28510 / 111.37 GiB Free PE / Size 0 / 0 VG UUID nq8fye-SpVe-cHrd-AM99-YWdA-7SPp-L3S2Hm --- Logical volume --- LV Path /dev/wheezy/SWAP LV Name SWAP VG Name wheezy LV UUID VbC1TX-2Ppz-1003-VFqU-0o0X-otwu-qy5Xam LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:36:55 +0000 LV Status available # open 2 LV Size 7.45 GiB Current LE 1907 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:1 --- Logical volume --- LV Path /dev/wheezy/TMP LV Name TMP VG Name wheezy LV UUID btQknc-WeBv-q2xA-dhz0-GsqR-G2hn-gKwCh0 LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:37:05 +0000 LV Status available # open 1 LV Size 10.79 GiB Current LE 2761 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:2 --- Logical volume --- LV Path /dev/wheezy/base LV Name base VG Name wheezy LV UUID dWD7ro-ACQ6-04O2-rKd2-iMCe-HddW-kX1mt6 LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:37:13 +0000 LV Status available # open 1 LV Size 93.13 GiB Current LE 23842 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:3 --- Physical volumes --- PV Name /dev/dm-0 PV UUID 8DEe3m-NaQC-mRia-cMfv-OO2O-Foog-XXTLeU PV Status allocatable Total PE / Free PE 28510 / 0 root@wheezy:~# lvdisplay -v Finding all logical volumes Incorrect metadata area header checksum on /dev/sda1 at offset 4096 --- Logical volume --- LV Path /dev/wheezy/SWAP LV Name SWAP VG Name wheezy LV UUID VbC1TX-2Ppz-1003-VFqU-0o0X-otwu-qy5Xam LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:36:55 +0000 LV Status available # open 2 LV Size 7.45 GiB Current LE 1907 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:1 --- Logical volume --- LV Path /dev/wheezy/TMP LV Name TMP VG Name wheezy LV UUID btQknc-WeBv-q2xA-dhz0-GsqR-G2hn-gKwCh0 LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:37:05 +0000 LV Status available # open 1 LV Size 10.79 GiB Current LE 2761 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:2 --- Logical volume --- LV Path /dev/wheezy/base LV Name base VG Name wheezy LV UUID dWD7ro-ACQ6-04O2-rKd2-iMCe-HddW-kX1mt6 LV Write Access read/write LV Creation host, time wheezy, 2014-11-24 16:37:13 +0000 LV Status available # open 1 LV Size 93.13 GiB Current LE 23842 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:3 root@wheezy:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 92G 25G 63G 28% / udev 10M 0 10M 0% /dev tmpfs 3.2G 1.3M 3.2G 1% /run /dev/mapper/wheezy-base 92G 25G 63G 28% / tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 6.3G 0 6.3G 0% /run/shm /dev/sda1 228M 30M 187M 14% /boot /dev/mapper/wheezy-TMP 11G 172M 10G 2% /tmp root@wheezy:~# pvs Incorrect metadata area header checksum on /dev/sda1 at offset 4096 PV VG Fmt Attr PSize PFree /dev/dm-0 wheezy lvm2 a-- 111.37g 0 /dev/sda1 lvm2 a-- 243.00m 243.00m root@wheezy:~# vgs Incorrect metadata area header checksum on /dev/sda1 at offset 4096 VG #PV #LV #SN Attr VSize VFree wheezy 1 3 0 wz--n- 111.37g 0 root@wheezy:~# lvs Incorrect metadata area header checksum on /dev/sda1 at offset 4096 LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert SWAP wheezy -wi-ao-- 7.45g TMP wheezy -wi-ao-- 10.79g base wheezy -wi-ao-- 93.13g What would be the best workaround to fix the corrupted metadata header? I have an identical machine (same hardware, same partitions, same wheezy installation, same apt sources) running without any problems. The second machine doesn't have this output in the pvdislay-command: "/dev/sda1" is a new physical volume of "243.00 MiB" --- NEW Physical volume --- PV Name /dev/sda1 VG Name PV Size 243.00 MiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID fnKsgr-KC2h-inYi-jhli-YFil-edTh-RsRTzK

Is it possible to boot from a system where /boot is located within an lvm2 raid1 partition. I've tried a variety of configurations, but I have yet to discover how to do it. I am using two 2TB disks. Each disk contains a GPT partition table with a 1MB bios_grub partition and a 2TB partition. The large 2TB partition on each disk is allocated as a physical volume to lvm2. I am using Ubuntu 14.04 LTS as my OS. Initially I configured Ubuntu with two 5GB logical volumes. The first one for / and the second for /home. The Ubuntu setup did not have options to configure these logical volumes with a segment type of raid1. So, I just installed it with what it defaulted to, which was linear. This worked fine and the system booted without any issues. I then rebooted into a live CD environment, and converted the two partitions into raid1 with the following commands. lvconvert --type raid1 -m1 /dev/vg_storage/os_root lvconvert --type raid1 -m1 /dev/vg_storage/os_home These operations completed without any errors. I then monitored the progress of lvm2 mirroring both of these logical volumes until copy% was 100% root@ubuntu:~# lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert os_home vg_storage rwi-a-r-- 4.66g 100.00 os_root vg_storage rwi-a-r-- 4.66g 100.00 Now the system fails to boot. I get the following error immediately after BIOS attempts to boot from the first of the two disks. And I am left with a grub rescue prompt. error: disk 'lvmid/L1VIor-PKIM-mtCO-TUQ2-iWe2-ndnY-df2wOu/yCDXMZ-2q4X-jbJJ-qZhI-sHNL-hrjw-Q5bg6v' not found. Entering rescue mode... grub rescue> I'm thinking there is a grub2 module that isn't being loaded. One that supports the raid1 functionality of lvm2. Either that or such support does not yet exist within grub2.

I have an issue with a virtual machine running Nextcloud and the version is Ubuntu 22.04 LTS. The system continuously indicates that the logical volume /dev/mapper/ubuntu--vg-ubuntu--lv is full (used 100%). To keep the system running, I’ve had to continuously expand the virtual disk size and extend the logical volume (using this guide ). The logical volume currently has 440GB of size, with 35GB free. Nextcloud storage and a backup disk are mounted in /mnt: Nextcloud storage /mnt/nextcloud is an iSCSI disk on a NAS, currently holding 3TB of data. The backup disk (348 GB) is also mounted in /mnt (/mnt/carpetarespaldosnas).

miusuario@nextcloud:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              3.2G  1.7M  3.2G   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  440G  387G   35G  92% /
tmpfs                               16G   28K   16G   1% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  254M  1.6G  14% /boot
/dev/sda1                          1.1G  6.1M  1.1G   1% /boot/efi
/dev/sdb1                           24T  3.1T   20T  14% /mnt/nextcloud
tmpfs                              3.2G  4.0K  3.2G   1% /run/user/1000

miusuario@nextcloud:~$ sudo du -cha --max-depth=1 /mnt 2>/dev/null
1.3G    /mnt/NCBACKUP-OLD
1002M   /mnt/NCBACKUP
4.0K    /mnt/ncdata
3.1T    /mnt/nextcloud
349G    /mnt/carpetarespaldosnas
3.5T    /mnt
3.5T    total

Since the logical volume is mounted on /, I tried various ways to get its total size to locate what was using the space, but it doesn’t show more than 30G used.

miusuario@nextcloud:~$ sudo du -cha --max-depth=1 --exclude=/mnt / 2>/dev/null
0       /lib64
28K     /dev
0       /proc
4.5G    /usr
4.0K    /opt
260M    /boot
4.0K    /media
0       /libx32
0       /sbin
0       /lib32
308K    /home
3.8G    /swap.img
1.8G    /snap
124M    /root
1.7M    /run
240K    /tmp
20G     /var
0       /bin
0       /lib
4.0K    /srv
16K     /lost+found
11M     /etc
0       /sys
30G     /
30G     total

So, I have no idea what is filling up the disk or what is actually using the space.

I have a setup with a grub2 bootloader, and the rest of the system on an encrypted partition (LVM-on-LUKS). I have two OSes installed inside of the LUKS container, Kali Sana and Debian 8, as well as a shared swap partition. This was setup by installing Kali with full disk encryption, and then making room for Debian. The grub install is from Kali. I am fully aware that it is simply easier to have a second /boot partition for Debian. However, given the way this was setup, there is no room left for the Debian bootloader, and resizing everything to make room will be a pain. So, here is what I need to do under grub: - Mount the encrypted partition (already managed to do this) - Start initramfs and the kernel for Debian (This is where there is trouble). I have done some research on this, and I am attempting to do this by editing the /boot/grub/custom.cfg file. After each edit, I have run sudo grub-mkconfig and sudo update-grub. Then I have restarted to see if it will boot. While it can decrypt the LUKS container, it can't find initramfs or the kernel. Here is my custom.cfg file. Note: I am fuzzy on what all of this does. It is most likely completely wrong. menuentry "Debian 8 Jessie"{ insmod luks insmod lvm cryptdevice=UUID=ffe7a64d-e552-4db9-b0f3-1e42be118059:cryptolvm set root=/dev/Outsider-vg/Outsider-debianroot linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/Outsider-vg/Outsider-debianroot initrd /boot/initrd.img-3.16.0-4-amd64 } Note about the above: cryptdevice=UUID=ffe7a64d-e552-4db9-b0f3-1e42be118059:cryptolvm was originally set root=/dev/sda5. This version of the file fails to decrypt the container. Note that I already know how to get this to work, I was just messing with it to see if changing it would help. I have been referencing [this link](https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS) for help editing this file. Basically, I need to know the syntax to point grub at the correct initramfs and vmlinuz files, after the LUKS partition has been decrypted. They are under the logical volume Outsider--debianroot. My only real issue is that I don't know how to do this. I apologize for being somewhat vague. Part of the problem is that I am not sure what I am looking for. If you do not have an answer, but can direct me to a comprehensive guide to editing custom.cfg, that would also be appreciated. Please let me know if you need more details. **EDIT: Upon further research, here is what I have found:** Basically, I need to give Grub the correct path to a root directory which is on an LVM. After doing some digging around on the file system, I have found two paths which could work: /dev/mapper/volumeGroup-volumeName and /dev/volumeGroup/volumeName. In the case of the above example, they are /dev/mapper/Outsider--vg-Outsider--debianroot and /dev/Outsider-vg/Outsider-debianroot. I need to know which is the path to the correct root directory, allowing that distro to boot. Either one is right, both need to be used together, or there is a different path which I am missing which I need to use instead. Any ideas? Furthermore, what is the difference between these two paths? What do they each point to? What is the difference between /dev/mapper/volumeGroup and just /dev/volumeGroup? **EDIT 2:** I believe that /dev/volumeGroup/volumeName is the correct path, based off of the end syntax for [this tutorial](http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/) . I will experiment with this and report back. Note: I will come and clean this up later, when I have solved it.

If you all look at the enclosed image above, you can see that I've merged four hard drives into one volume group called MQ. I did this in order to try to have my system hard drive (KINGSTON SUV400S) merged with the volume group MQ so that it would show up as one big system drive. The reason why I want to do this is so I can install all the additional graphics drivers I need for Ollama to run my AI model on my GPU and not just my CPU, as it is now. The reason for why I'm asking this question is because the system drive ran out of storage space when I installed the graphics drivers which made the computer unbootable for a while. Can someone give me directions on how to do this, or is this impossible?

LVM and mdadm/dmraid both offer software RAID functionality on Linux. This is essentially a follow-up to a question from 2014 . Back then, @derobert recommended using mdadm over LVM RAID due to its maturity — but that was more than four years ago. I imagine things may have changed since then. However, I’ve never used LVM RAID before, and I couldn't find many recent experiences or discussions about it. So, what’s the current state of LVM RAID? Has it become more mature? Have the flaws mentioned in @derobert’s post been resolved, or do they still exist? Specifically, how does it compare to mdadm in terms of: - Stability - Features (grow, shrink, convert) - Repair and recovery - Community support - Performance I’d like to know if people actually use LVM RAID now, or if most still stick with mdadm. Is it more advisable to use LVM on top of mdadm for logical volume management, or is it now acceptable to let LVM manage the RAID as well? Would it even make sense to use LVM RAID instead of mdadm, even if you don’t plan to take advantage of logical volume management? I considered commenting on the original answer and asking @derobert for an update, but I decided to post a new question to reach more community members and gather fresh perspectives — not just update the original post to the present tense.

Today I'm configuring kickstart, and when I tried to set the LVM sizes, Anacond protests that there is no free space to create LVM with VG size. Well I could figure out that --grow option can continue the installation w/out prompt to solve this problem, but I need to know how I can calculate the correct VG size to group my LVMs? I just could see something related in AIX system but I thing that is not about my question, and no that isn't a bug. Error: **storage configuration failed: ('new lv is too large to fit in free space', 'vg00')** The wrong configuration: part /boot --fstype="xfs" --ondisk=vda --size=500 part pv.01 --fstype="lvmpv" --ondisk=vda --size=9500 --grow volgroup vg00 --pesize=4096 pv.01 logvol / --fstype="xfs" --size=9000 --name=root --vgname=vg00 logvol swap --fstype="swap" --size=250 --name=swap --vgname=vg00 logvol /home --fstype="xfs" --size=250 --name=home --vgname=vg00 The correct configuration: part /boot --fstype="xfs" --ondisk=vda --size=500 part pv.100 --fstype="lvmpv" --ondisk=vda --size=9739 volgroup vg00 --pesize=4096 pv.100 logvol swap --fstype="swap" --size=250 --name=swap --vgname=vg00 logvol /home --fstype="xfs" --size=250 --name=home --vgname=vg00 logvol / --fstype="xfs" --size=9000 --name=root --vgname=vg00 When I used the --grow option in partition, the kickstart create a anaconda-ks.cfg with that configuration above, I just can't understand how the size=14079 is calculated. The original-ks.cfg have the option --grow ;) Could someone give a idea about LVM math? Thx