Quickly summarizing and picking up where things previously left off (from this link for Part 1), the two 100GB Logical Volume Manager (LVM2) physical file segments have been mounted as a single 215GB logical volume and can now be accessed as a live file system.
Summary and Review
To quickly review, at this point two LVM2 files called LinuxSvr-CLONE_1-flat.001 and LinuxSvr-CLONE_2-flat.001 have been successfully mapped to the path /dev/mapper/VolGroup[redacted] and then mounted at /media/sansforensics/. Viewing the console output confirms that the two 100GB files have been successfully "stitched together" as a single 215GB volume and mounted at:
Imaging the Mounted LVM2 Volume
With that confirmation in place, the forensic imaging process can now begin. Using the mapped file above as input along with dcfldd (just because I like the feedback/status as compared to standard 'dd'), the output will be written to a generically named LVM2_200GB.001 file using /dev/mapper/VolGroup[redacted]as the input file. We'll go ahead and fast forward to the end of the imaging process since it takes several hours to complete, as shown below:
So let's mount it and see if it's valid image file. For this example, the pre-existing folder /mnt/aff/ on the SIFT workstation is randomly selected as the mount point.
Unmounting and Detaching the Volumes
And so at this point the obvious question is how to get all of this stuff undone as well as cleanly unmounting/detaching:
(1) the 215GB dd output file that was just created and (2) both source 100GB dd files used to create it.
A simple sudo umount /mnt/aff command is the first option (although I forgot to 'sudo' during the first attempt in the example, hence the initial error message). So let's unmount it, then cd back into the directory and use ls to see if there's still something there:
They need to be detached by using the LVM command set. The previously used losetup command can be used with the -d option (detach) to accomplish that. We'll run sudo losetup -d on both loop devices to detach them cleanly:
So the next step is to query the device mapper for some information about the mappings to see if that might be the likely cause of the problem. Using the command sudo dmsetup info for a quick peek into the state of things, the following information is returned:
Note that the targeted device to detach, VolGroup[redacted], was pinpointed by using the item listed on the Name: row (resulting from the previous dmsetup info command above).
The end has arrived. The individual (smaller) physical disk images files have been individually imaged and then successfully combined into the larger LVM2 logical volume spanning across the physical files. Along with much troubleshooting along the way.
The LVM2 volume was successfully mounted, imaged as one large LVM2 into dd format, then verified to be a functional image file, along with the larger/combined dd file being unmounted without issues.
And finally, the source image files (used to generate the combined volume that was ultimately imaged) were detached as an active device while using a few troubleshooting techniques to find the correct way to detach them.
In conclusion I'll admit this seems to be a fairly niche DFIR topic for the moment but I suspect it's going to grow to be a fairly common issue. Hopefully this posting will help others figure things without having to reinvent the forensic wheel.
I'd also like to thank those who responded to me about other ways to approach this. I'll be experimenting with them to see if there's another way / better way to perform this activity or provide some alternatives.