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.