On 11/26/2020 07:19 PM, H wrote: > On 11/26/2020 05:27 PM, Leon Fauster via CentOS wrote: >> Am 26.11.20 um 20:10 schrieb H: >>> Running CentOS 7 I have a previously combined backup of a disk with three partitions using dd. I now need to restore one single file from this backup and after perusing the internet, specifically https://unix.stackexchange.com/questions/31669/is-it-possible-to-mount-a-gzip-compressed-dd-image-on-the-fly, I have done the following: >>> >>> - installed squashfs-tools >>> >>> - installed kpartx >>> >>> - made a squash image of the dd backup and mounted it >>> >>> - used kpartx to create devices for the three partitions under /dev/mapper/loopNpP >>> >>> - I can now mount the first partition, which is the EFI partition, and access it >>> >>> - the second partition, the boot partition, fails to mount since it has the same UUID as the disk I am using in the computer, and of which it is an earlier dd backup. Since I am not interested in the boot partition - at least not right now - I moved on. >>> >>> - I am, however, interested in the third partition which is LUKS encrypted. Running 'cryptsetup luksOpen /dev/sda3 my_encrypted_volume' I can decrypt it with the password >>> >>> - trying to mount the decrypted version with 'mount /dev/mapper/my_encrypted_volume /media/my_device' results in a failure message 'mount: unknown filesystem type 'LVM2_member' >>> >>> - another website, https://askubuntu.com/questions/766048/mount-unknown-filesystem-type-lvm2-member, suggests I could run vgdisplay to get the UUID and then rename it using vgrename >>> >>> But, vgdisplay shows only one vg and I am afraid to rename the VG UUID shown by vgdisplay since it might refer to the VG currently in use... >>> >>> Does anyone have any insight or suggestions into the above and how to proceed while being absolutely certain I will not be messing up the running part of the system? >>> >> IIRC: Activate the LVM via: vgchange -a y >> >> and mount the logical volume (LV). >> >> LV can be listed with lvs. The device nodes are under /dev/mapper ... >> >> -- >> Leon >> >> >> >> >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > OK, I am looking at https://www.cyberciti.biz/faq/linux-mount-an-lvm-volume-partition-command/. A couple of follow-up questions: > > - Would activating the LVM with 'vgchange -a y' make any changes, or create any potential issues, with the system already running? > > - How do I know that the output from 'vgdisplay' refers to this 'new' VG and not VGs on the running system? > > - To mount the VG, I would have to run: > > -- 'vgscan' > > -- make directory for mounting > > -- 'mount...' to mount the VG > > Is that correct? And it would not create any issues with the running system? > > Thank you in advance. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos OK, finally had time to delve into this and become a LVM expert (ha!) I got it working and can retrieve files from old dd images, both unencrypted and LUKS encrypted. Note that I did this on another computer than the dd images were made from to avoid UUID conflicts. However, a couple of questions: Section 1: I had no problems mounting and accessing the files for the boot partition but since the home partition is a "LVM2_member", I had to go through some extra steps such as: "vgimportclone --basevgname -i /dev/mapper/mev" (the latter location is an arbitrary name chosen by me) This results in error message: "Error writing device /dev/mapper/mev at 4096 length 512. bcache_invalidate: block (6, 0) still dirty Failed to write mda header to /dev/mapper/mev fd -1" Question 1: - What does this error message really mean? Is this something I ought to fix (although I blithely continued as below...) Section 2: However, after running lvscan, vgchange -ay, ls -lh /dev/mapper to find out which /dev/dm-* to mount (/dev/dm-7) in my case: "mount -o ro,loop /dev/dm-7 mtb3" (the latter again is a mount point arbitrarily chosen by me) Results in another error message about a missing superblock which could be corrected by: "mount -o ro,loop,norecovery /dev/dm-7 mtb3" I was then able to recover the couple of files I needed. Question 2: - Should I do something different when eventually mounting to avoid the error message about a missing superblock? Or is there something wrong with the disk partition I had copied by dd? Looking forward to insight by those more knowledgeable than myself. Many thanks.