Mount and Extract files from images
-
@BedCruncher Ouch! Not going to suggest those partclone-utils anymore. After playing a little bit with those tools without being successful in regards of actually mounting an image I now have two (four) very ugly un-interruptable processes in my process list:
ps ax | grep imagemount 7979 ? Ds 0:00 /path/to/partclone-utils-0.2.1/src/imagemount -d /dev/nbd0 -f disk.img -m /mnt/ -t ntfs 7980 ? Z 0:00 [imagemount] <defunct> 8020 ? D 0:00 /path/to/partclone-utils-0.2.1/src/imagemount -d /dev/nbd0 -f disk.img -m /mnt/ -t ntfs 8023 ? Z 0:00 [imagemount] <defunct>I probably need to reboot to get rid of those. This tool is definitely a bit odd and probably needs some good work to make it work.
[edit]At least I was able to clean things up by starting imagemount as a foreground process and enable verbose logging like this
./imagemount -d /dev/nbd0 -f sys.img -m /mnt/ -t ntfs -Dr -v 2- but still there is nothing in/mnt. Some image files even fail with weird “No such file or directory” errors although the file does exist and is readable. I have no idea…[/edit] -
There is another project called partclone-nbd. Although I had to modify CMakeList.txt (change version from 3.1 to 3.0 as debian comes with cmake 3.0.2) and src/signals.c (define the loop counter before the for loop) to be able to build that tool.
/path/to/partclone-nbd/partclone-nbd -c sys.img [ DBG ] Log file initialized. [ DBG ] Image file opened. [ DBG ] Image header readed. [ DBG ] Correct image signature. [ DBG ] Detected supported image version 0001. [ DBG ] Header data loaded. [ DBG ] [ DBG ] Information from header: [ DBG ] - device size: 532417536 bytes [ DBG ] - blocks count: 98138 [ DBG ] - used blocks: 16499 [ DBG ] - block size: 4096 bytes [ DBG ] - checksum size: 4 bytes [ DBG ] - blocks per checksum: 1 [ DBG ] [ DBG ] Bitmap type is "byte". [ DBG ] Memory required by bitmap: 12272. [ DBG ] Memory for bitmap allocated. [ DBG ] Bytemap mapped to memory. [ DBG ] Correct bitmap signature. [ DBG ] Bytemap loaded to bitmap. [ DBG ] Bytemap unmapped. [ DBG ] Bitmap created. [ DBG ] Memory required by cache array: 24. [ DBG ] Memory for bitmap cache allocated. [ DBG ] Cache created. [ DBG ] Image image created. [ INF ] Image loaded. [ DBG ] A pair of sockets created. [ DBG ] /dev/nbd0 device opened. [ DBG ] NBD device socket cleared. [ DBG ] Socket for communication with kernel set. [ DBG ] Image block size (4096) sent. [ DBG ] Number of blocks (98138) sent. [ DBG ] Read only device attribute set. [ DBG ] Lock thread created. [ DBG ] Memory for storing a chunk allocated. [ DBG ] Signal return point set. [ DBG ] SIGHUP handler set. [ DBG ] SIGINT handler set. [ DBG ] SIGTERM handler set. [ DBG ] SIGQUIT handler set. [ DBG ] SIGUSR1 handler set. [ DBG ] SIGUSR2 handler set. [ INF ] Waiting for requests ...Looks promising I thought. But when I try mounting /dev/nbd0 I get:
ntfs-3g-mount: mount failed: Permission denied(yes I am root!) - not sure what I’m doing wrong.[edit]Ok, getting closer I suppose. Tried a different image (all dummy test images). When trying to mount I get this:
Failed to read last sector (204798): Invalid argument HINTS: Either the volume is a RAID/LDM but it wasn't setup yet, or it was not setup correctly (e.g. by not using mdadm --build ...), or a wrong device is tried to be mounted, or the partition table is corrupt (partition is smaller than NTFS), or the NTFS boot sector is corrupt (NTFS size is not valid). Failed to mount '/dev/nbd2': Invalid argument The device '/dev/nbd2' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? -
@BedCruncher @Sebastian-Roth @Tom-Elliott
Hi, i even tried it and it worked like a charm on ubuntu 14.04, it would be a really cool improvement when this could be done directly in the fog webinterface, lets say a button in the image management that could be clicked.
When extraction and mounting is finished send email when configured and or use the pushbullet plugin to tell the admin that image extraction and mounting is finished.
Lets say we have a fixed mount point for example /mnt we can configure samba to easily access the moint point from a remote machine.
Finally we need another webif button to umount and delete the extracted image when finished restoring.
Another idea is to automatically umount the restore mountpoint and delete the extracted image after lets say 24 hours (maybe cron driven) because after that amount of time restoring files should be finished and that way the admin cannot forget to umount the restore point and to delete the extracted image. Anyway if the storage is big enough that should not harm the system until the next image has to be restored.
Don’t forget additional Storage Nodes, this have to work with Main Fog and additional Storage Nodes, where ever the Image is stored.
What do you guys think about that?
EDIT:
I found the following on the web:
zcat sda5.ext4-ptcl-img.gz.aa | partclone.ext4 -C -s - -r -o /mnt/sda1.loop.img --restore_raw_filehttps://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/4db4b2bd/#8d04
Regards X23
-
Maybe something like that:
-
@x23piracy
Where did you find that link? I’d like to run it through a translator to be able to see what it says. -
@BedCruncher it’s just a case study, some photoshopping not an existing option, i just wanted to show what i would expect from that option, for the case it becomes true
Regards X23
-
@x23piracy
Sorry, I didn’t perhaps explain what I was referencing. I was meaning the comment you had posted prior to this last series of images. The one that was authored by Thorsten F. -
@BedCruncher ah okay
here is a bad translation from google:Probably it works as described , but after studying the manual pages of part clone I recommend rather the following call : sudo partclone.ext4 -r -W -C -L partclone.log -s sda10.ext4 - PTCL img -o sda10.img I call on partclone.ext4 because the developer device itself , no longer partclone.restore to use . After that is " -r " for restore , " -W " for the Create a file that you can embed a loop device ( which is missing in the post completely , I think ) , " C " that the free space is not checked is , " -L partclone.log " for a log file in the current directory , " -s " for the input file ( here, of course - if one of gzip out pipet ) and " -o " for the output file . I found it as easy to strange a directory " / dir " in the root directory to create - why not just a file in loakeln directory , or wherever there is enough space , create ? reply
Original link: https://simonstamm.de/clonezilla-image-mounten-um-einzelne-dateien-wiederherzustellen/
Regards X23
-
@x23piracy
Wow, google for the Mangle Translation Win. -
@Sebastian-Roth
Did you ever get anywhere with the alternate client/project that you were looking at? Just curious. -
@BedCruncher You mean partclone-nbd? Well I am actually not very interested in this kind of feature so I didn’t really dig into this. Just tried to help you finding something. Sorry if it sounded like I’d be pushing this. Not saying that we shouldn’t add it but I don’t have the time to do it! Feel free to play with it and let us know if it is working properly.
-
@Sebastian-Roth
No worries there. I just knew that you were looking at it some. It’s no biggie. I’ll try to track it down and work with it, but at a slower pace, don’t want to roll something like that out and possibly mess up my prod server. Thanks for all your help with this manner. -
Hi, I’m partclone-nbd developer. I know this thread is quite old, but maybe I could help (or you could help me in solving some issues :)). I used partclone-nbd to read several ext4 images, and I’ve never experienced any problems.
Furthermore, it is strange that you have to change the code. Defining the loop counter inside the for loop is a C99 extension, and CMakeLists.txt states clearly:
set( CMAKE_C_STANDARD 99 )@Sebastian-Roth It would be amazing if you could tell me which version of partclone was used to create dummy images. Or maybe you could share those dummy test images?
@BedCruncher Have you already tried partclone-nbd?
-
@pr1m0
I haven’t tried that sadly. All of the times I’ve had to get files out of images, it’s not been too much of a hassle. Although I would be open to trying it if you might could provide some pointers on getting it going in Centos 7. -
@pr1m0 Thank’s a lot for getting in touch here! The images I used back then where created using partclone 0.2.88 or maybe 0.2.80. Unfortunately I do not have much time these days to do some extensive testing. Hope this information can help in getting this to work for BedChruncher…
-
@Sebastian-Roth @Wayne-Workman @Junkhacker @george1421 @x23piracy @pr1m0
Sorry to dredge up an old topic, but I went back and tried to redo the steps that I had originally done to restore an image using purely the server. While the steps I listed will work, I did originally mention it, but didn’t specifically include the steps to restore the image on the server. Here is the current working 100% steps to make this all work properly.
Without the touch command below it will error out. So otherwise this works as expected.
cd /images/IMAGENAME/ touch d1p2_extracted.img cat d1p2.img | pigz -d -c | partclone.restore -C -s - -O d1p2_extracted.img mount -t ntfs-3g d1p2_extracted.img /mnt -
@BedCruncher Very interesting…
Thank you for the additional clarity on making this work smoothly.
-
#wiki worthy because this has use cases. All the components needed are in this thread - but I’ll approach it from a workstation perspective - don’t want to monkey around too much on potentially a production fog server.
-
In my case I actually did the following so that I didn’t mess up the working directory or it’s file contents
touch /tmp/d1p2_extracted.img cat d1p2.img | pigz -d -c | partclone.restore -C -s - -O /tmp/d1p2_extracted.img mount -t ntfs-3g /tmp/d1p2_extracted.img /mntjust dumped it to /tmp so that it would be deleted during normal system processes and not fill up my images directory with double images.
-
@BedCruncher This is only an FYI note for those who may find this thread in the future.
The developers have added a new and faster compression/decompression tool in the current release of fog (1.3.5 and later). This is the zstd compression tool instead of the pigz tool. You just have to be aware of this. The zstd tool should read pigz compressed files no problem. But pigz can not read zstd compressed files.
