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@xxxxxxxxxx
>> 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@xxxxxxxxxx
> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
