Clonezilla / Bugs / #253 LVM2 issue - Cannot process volume group vg

Steven Shiau - 2016-06-26

Thanks for the bug report. We will do some more tests here to see if this issue can be reproduced or not. If it's reproducible, then it can be fixed.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2016-06-27

Could you please attach the files lvm_*.conf and sda-pt.sf from the image dir?
Thanks.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mircea Dan - 2016-06-27

no lvm*.conf but i attached all the files that are readable with a text editor,

test@test:~$ sudo vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_01" using metadata type lvm2

test@test:~$ sudo lvscan
ACTIVE '/dev/vg_01/lv_home' [821.23 GiB] inherit
ACTIVE '/dev/vg_01/lv_swap' [4.00 GiB] inherit

test@test:~$ sudo vgchange -a y
2 logical volume(s) in volume group "vg_01" now active

test@test:~$ sudo lsblk -o TYPE,NAME,KNAME,UUID,MOUNTPOINT,SIZE
TYPE NAME KNAME UUID MOUNTPOINT SIZE
disk sda sda 931.5G
part +-sda1 sda1 46DC-C4D6 500M
part +-sda2 sda2 4e075ebc-b069-4a4c-8425-035fda983a9d 500M
part +-sda3 sda3 b16eb8b2-adc7-47c0-aea0-c54f478b2954 31.3G
part +-sda4 sda4 1K
part +-sda5 sda5 31.3G
part +-sda6 sda6 4f25ad2c-2165-4541-bf5f-ca91b8928e10 31.3G
part +-sda7 sda7 CEPaXn-bt3A-hCso-vUGW-5vuc-CWN3-oSjqyo 825.3G
lvm +-vg_01-lv_home dm-0 1c5aa436-0398-4df2-99cf-2a39b53f865e 821.2G
lvm +-vg_01-lv_swap dm-1 db886ddc-2bdf-4212-84fc-4cec08e64630 4G
disk sdb sdb 57.9G
part +-sdb1 sdb1 21c443e4-7ae1-4b37-a426-e9e5b497e162 / 55.4G
part +-sdb2 sdb2 1K
part +-sdb5 sdb5 c8db8cde-9df5-4c93-8183-1f0f819364f3 [SWAP] 2.5G

Last edit: Mircea Dan 2016-06-27

test-image-logs.zip

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2016-06-27

No lvm_*.conf? Without that, the LVM won't be able to rebuild. That's why LV won't be restored. I believe something went wrong when saving. No wonder I can not reproduce the issue here.
Please run
find /home/partimag/$YOURIMAGE -print
(Replace $YOURIMAGE with your image name)
then post the results.
Thanks.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mircea Dan - 2016-06-28

test@test:~$ sudo find /home/partimag/test-image -print
/home/partimag/test-image
/home/partimag/test-image/dmraid.table
/home/partimag/test-image/blkdev.list
/home/partimag/test-image/blkid.list
/home/partimag/test-image/dev-fs.list
/home/partimag/test-image/sda-pt.sf
/home/partimag/test-image/sda-chs.sf
/home/partimag/test-image/sda-pt.parted
/home/partimag/test-image/sda-pt.parted.compact
/home/partimag/test-image/sda-hidden-data-after-mbr
/home/partimag/test-image/sda-mbr
/home/partimag/test-image/sda1.vfat-ptcl-img.gz.aa
/home/partimag/test-image/sda2.ext4-ptcl-img.gz.aa
/home/partimag/test-image/sda3.ext4-ptcl-img.gz.aa
/home/partimag/test-image/sda5.dd-img.aa
/home/partimag/test-image/sda6.ext4-ptcl-img.gz.aa
/home/partimag/test-image/lvm_vg_dev.list
/home/partimag/test-image/lvm_logv.list
/home/partimag/test-image/test-image-logs.zip

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2016-06-28

Yes, something went wrong when saving the LVM layout with vgcfgbackup. If your LVM system still remains, can you save it as an image again and check if the LVM config file can be saved by vgcfgbackup? If not, please post the error messages.
Thanks.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mircea Dan - 2016-06-29

i think i found the issue and made some progress and i'm not sure how it can be resolved
is something related to having 2 drives sda and nbd0 both having an lvm with same name

test@test:~$ sudo vgscan
Reading all physical volumes. This may take a while...
Found duplicate PV IG6O6XLdCNLVEwRfGSlY13cR5uH4UAfl: using /dev/nbd0p7 not /dev/sda7
Using duplicate PV /dev/nbd0p7 without holders, replacing /dev/sda7
Found duplicate PV IG6O6XLdCNLVEwRfGSlY13cR5uH4UAfl: using /dev/nbd0p7 not /dev/sda7
Using duplicate PV /dev/nbd0p7 without holders, ignoring /dev/sda7

so i'm wipeing out completley the sda
and as can be seen from the commands attached the lvm shows fine for nbd0 and also vgcfgbackup works with no problem

but as soon as the partition table is copied from nbd0 to sda, the lvm becomes active on sda drive and nbd0 is not showing it anymore

how is this problem solved for disk2disk cloning when there are lvms involved

1) fresh boot
sda 2 image : works fine now (i don't connect nbd0 device)

2) fresh boot
wipe sda completley (see commands attached)
connect nbd0
nbd0 2 image works fine now (but sda must be clean)

3) fresh boot
wipe sda (if i don't wipe sda it will show either the lvm on sda or either on nbd0 but not both)
connect nbd0
refresh lvm
nbd0 2 sda -> does dd copy of nbd0p7 <---- this is the current problem

the problem above or the curent one all seams related to the fact that source and target disk will have for a while same lvm names and that creates trouble.

Last edit: Mircea Dan 2016-06-29

commands.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mircea Dan - 2016-06-29

and the lvm config file, i'm using now the latest version that came out 1-2 days ago

see the commands file uploaded above, the command was issued right before starting clonezilla.

Last edit: Mircea Dan 2016-06-29

vg_01

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2016-06-29

You can NOT have 2 identical LVMs on the same machine. Therefore before imaging one of them, please remove the other one from the machine. Otherwise it will confuse the GNU/Linux system. This is like you can not have same UUIDs for 2 file systems on the same machine. The system will be in a mess in that case.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

so i wipe the first drive completley and all show good. consider sda a blank a destination drive
and nbd0 is the source drive that has all partitions lvm and data.

when clonezila copies the partition table from nbd0 to sda and does a refresh than the conflict is created.

Will create the partition on the target machine...
Failed to stop mkswapfile.service: Unit mkswapfile.service not loaded.
Shutting down the Logical Volume Manager
  Shutting Down volume group: vg_01
Finished Shutting down the Logical Volume Manager
Trying to clean the MBR and GPT partition table on the destination disk first: /dev/sda
Informing the OS of partition table changes... done!
Creating MBR type's partition table...
No partition table exists in target disk /dev/sda, try to initialize one so that we can get the disk size by parted... Running: parted -s /dev/sda mklabel msdos
done!
sfdisk --force /dev/sda < /tmp/ocs_onthefly_local.01lQZQ/tgt-pt.sf
Checking that no-one is using this disk right now ... OK

Disk /dev/sda: 931.5 GiB, 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
Disklabel type: dos

**and now the conflict is created, dev sda has same volume name as dev nbd0**

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1            2048    1026047    1024000   500M  6 FAT16
/dev/sda2  *      1026048    2050047    1024000   500M 83 Linux
/dev/sda3         2050048   67586047   65536000  31.3G 83 Linux
/dev/sda4        67586048 1929379839 1861793792 887.8G  5 Extended
/dev/sda5        67588096  133124095   65536000  31.3G 83 Linux
/dev/sda6       133126144  198662143   65536000  31.3G 83 Linux
/dev/sda7       198664192 1929379839 1730715648 825.3G 8e Linux LVM

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
This was done by "sfdisk --force /dev/sda < /tmp/ocs_onthefly_local.01lQZQ/tgt-pt.sf"
Informing the OS of partition table changes.... done!
Checking the integrity of partition table in the disk /dev/sda...
done!

is it posible for clonezilla to create a temp name for lvm untill the very last second and rename the lvm back once all other operations are completed.

i'm not sure how disk2disk cloning is suposed to work when lvm exists then.

Last edit: Mircea Dan 2016-06-29

Steven Shiau - 2016-06-29

Yes, that's why dd is used when the LV is cloned. After the cloning finishes, before you boot the restored OS from the machine, you have to remove one of the disk. In the future we will add a warning to prompt this.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mircea Dan - 2016-06-29

my sugestion was if the lvm name is changed and then renamed back at the end of the cloning than it shoudl clone understanding the file system

create partitions and lvm
sudo vgrename /dev/vg_01 /dev/vg_clone : for the target drive (it may need to keep the lvm for source down at this point so it does not create conflict)
bring both lvms up
do the data cloning
take the source lvm down
sudo vgrename /dev/vg_clone /dev/vg_01 (for destination drive)
unplug source and reboot

is this something doable in order to suport disk 2 disk cloneing of lvm data in a faster way

Last edit: Mircea Dan 2016-06-29

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2016-07-03

Thanks for this suggestion. This should be a feature we can try in the future. Actually not only the LV name has to be changed, but also the UUIDs of them.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jesse Parrish - 2019-01-10

This sound all to familiar. I am trying to recover files from a deceased Seagate Central but want to clone the drive before trying to recover the files. Due to the size of the source disk the cloning operation must be disk to disk.

The starting point is Ubuntu PC with three HDD's: boot drive 1TB, Source Drive 4 TB (ext4, with LVM; pulled from Seagate Central enclosure), Taget Drive 4TB (fresh out of the box).

What are the steps to clone the source drive right the first time given the problems decribed above of having two identical LVM disks active at the same time?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LVM2 issue - Cannot process volume group vg_01

A partition and disk imaging/cloning program

Group

Searches

Help

#253 LVM2 issue - Cannot process volume group vg_01

Discussion