I created with partclone, the images of three partitions of the same hard drive.
I can mount one of them using "imagemount" while with the other two I get the error in question:
sdaN.img: cannot verify: Invalid argument
I used the 0.4.1 version of partclone-utils compiled by me.
My system is Lubuntu 16.04 x86_64 with kernel 4.4.0-36-generic.
I can not remember partclone version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to mention file system was "ext4" for all partitions.
I think this issue only occurs with earlier versions of partclone (the version of partclone with whom I created images was partclone-0.2.77 (contained in sysrescuecd 4.6.0)) because mounting an image created with partclone-0.2.86 (Lubuntu 16.04) I had no problems.
I will continue to do tests and in case, I will let you know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's a little utility that's built with the distribution of partclone-utils, partclone_imageinfo which dumps some cursory information about the file. Maybe if you could run that on the problematic file, that might provide some guidance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However I have also the log generated by partclone during image creation:
Partclone v0.2.77 http://partclone.org
Starting to clone device (/dev/sda1) to image (-)
Reading Super Block
we need memory: 160804 bytes
image head 4160, bitmap 152544, crc 4100 bytes
Calculating bitmap... Please wait... done!
File system: EXTFS
Device size: 5.0 GB = 1220352 Blocks
Space in use: 278.8 MB = 68078 Blocks
Free Space: 4.7 GB = 1152274 Blocks
Block size: 4096 Byte
Total block 1220352
Syncing... OK!
This is the output of that command on an image file running:
# partclone_imageinfo sda1.img
/tmp/sda1.img: 1220352 blocks, 1220352 blocks scanned, 1152274 unset, 68078 set, 0 strange
/tmp/sda1.img: size is 280344320 bytes, blocks (4096 bytes) start at 1224520: 68078 blocks written
/tmp/sda1.img: read last block at end of file
/tmp/sda1.img: OK
and this is the log generated by partclone during image creation:
Partclone v0.2.89 http://partclone.org
Starting to clone device (/dev/sda1) to image (-)
Reading Super Block
we need memory: 160804 bytes
image head 4160, bitmap 152544, crc 4100 bytes
Calculating bitmap... Please wait... done!
File system: EXTFS
Device size: 5.0 GB = 1220352 Blocks
Space in use: 278.8 MB = 68078 Blocks
Free Space: 4.7 GB = 1152274 Blocks
Block size: 4096 Byte
Total block 1220352
Syncing... OK!
Partclone successfully cloned the device (/dev/sda1) to the image (-)
As you can see, images have been created with two different version of Partclone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry - I just found this in the moderation queue. The partclone_imageinfo fails with errno 14, EFAULT, which indicates that the used blocks count in the header doesn't match the actual count. This was a bug in previous versions of partclone which was remedied by using the "tolerant" flag in imagemount, -T. My recollection is that this was fixed before the version of partclone that you had said you used, but I could be wrong.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-12-26
cannot verify: Invalid argument with partclone-utils version 0.4.1 on partclone version 0.3.11.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-01-20
I have the same problem with partclone 0.3.11 and partclone-utils 0.4.1. Imagemount with or without -T gives the "cannot verify: Invalid argument" error. Testing the image with partclone.info and partclone.chkimg shows no errors, but partclone_imageinfo gives a "cannot verify image (error = 2)" message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
error = 2 is ENOENT - no such file or directory. Check your command line argument.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-01-22
Yes, i checked the command line and when the file name is incorrect or non-existent, partclone_imageinfo gives a "cannot open image (error = 2)". With the correct file name, the message is "cannot verify image (error = 2)". Below is a little test using a VM.
Image created:
root@PartedMagic:/media/sda1# partclone.ext4 -c -s /dev/sdb1 -o sdb1.img
Partclone v0.3.11 http://partclone.org
Starting to clone device (/dev/sdb1) to image (sdb1.img)
Reading Super Block
Calculating bitmap... Please wait...
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%
Total Time: 00:00:01, 100.00% completed!
done!
File system: EXTFS
Device size: 8.6 GB = 2096896 Blocks
Space in use: 689.6 MB = 168371 Blocks
Free Space: 7.9 GB = 1928525 Blocks
Block size: 4096 Byte
Elapsed: 00:00:34, Remaining: 00:00:00, Completed: 100.00%, Rate: 1.22GB/min,
current block: 1606145, total block: 2096896, Complete: 100.00%
Total Time: 00:00:34, Ave. Rate: 1.2GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/sdb1) to the image (sdb1.img)
Cloned successfully.
Getting image info and checking the image:
root@PartedMagic:/media/sda1# partclone.info -s sdb1.img
Partclone v0.3.11 http://partclone.org
Showing info of image (sdb1.img)
File system: EXTFS
Device size: 8.6 GB = 2096896 Blocks
Space in use: 689.6 MB = 168371 Blocks
Free Space: 7.9 GB = 1928525 Blocks
Block size: 4096 Byte
image format: 0002
created on a: 32 bits platform
with partclone: v0.3.11
bitmap mode: BIT
checksum algo: CRC32
checksum size: 4
blocks/checksum: 256
reseed checksum: yes
root@PartedMagic:/media/sda1# partclone.chkimg -s sdb1.img
Partclone v0.3.11 http://partclone.org
Starting to check image (sdb1.img)
Calculating bitmap... Please wait...
done!
File system: EXTFS
Device size: 8.6 GB = 2096896 Blocks
Space in use: 689.6 MB = 168371 Blocks
Free Space: 7.9 GB = 1928525 Blocks
Block size: 4096 Byte
Elapsed: 00:00:14, Remaining: 00:00:00, Completed: 100.00%, Rate: 2.96GB/min,
current block: 1606145, total block: 2096896, Complete: 100.00%
Total Time: 00:00:14, Ave. Rate: 3.0GB/min, 100.00% completed!
Partclone successfully checked the image (sdb1.img)
Checked successfully.
Getting image info with partclone_imageinfo with file name in the current directory and with the full path:
Next test, i'll try a image created with partclone 0.2.89
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-01-22
UPDATE: With partclone 0.2.89 and partclone-utils 0.4.1 everything works well.
`root@PartedMagic:/media/sda1# partclone.ext4 -c -s /dev/sdb1 -o sdb1.img
Partclone v0.2.89 http://partclone.org
Starting to clone device (/dev/sdb1) to image (sdb1.img)
Reading Super Block
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%
Total Time: 00:00:01, 100.00% completed!
done!
File system: EXTFS
Device size: 8.6 GB = 2096896 Blocks
Space in use: 689.6 MB = 168371 Blocks
Free Space: 7.9 GB = 1928525 Blocks
Block size: 4096 Byte
Elapsed: 00:00:26, Remaining: 00:00:00, Completed: 100.00%, Rate: 1.59GB/min,
current block: 1606145, total block: 2096896, Complete: 100.00%
Total Time: 00:00:26, Ave. Rate: 1.6GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/sdb1) to the image (sdb1.img)
Cloned successfully.
root@PartedMagic:/media/sda1# partclone_imageinfo sdb1.img
sdb1.img: 2096896 blocks, 2096896 blocks scanned, 1928525 unset, 168371 set, 0 strange
sdb1.img: size is 692422164 bytes, blocks (4096 bytes) start at 2101064: 168371 blocks written
sdb1.img: read last block at end of file
sdb1.img: OK
root@PartedMagic:/media/sda1# modprobe nbd
root@PartedMagic:/media/sda1# imagemount -d /dev/nbd0 -f sdb1.img
root@PartedMagic:/media/sda1# mount /dev/nbd0 /mnt/loop
root@PartedMagic:/media/sda1# ls -l /mnt/loop
total 20
drwxr-xr-x 4 root root 4096 Jan 22 16:24 lib
drwx------ 2 root root 16384 Jan 22 16:22 lost+found`
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is that the latest versions of partclone use the image format version 0002. I have forked partclone-utils here https://github.com/prekageo/partclone-utils and added support for the image format version 0002.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are correct: the current latest partclone-utils tarball on Sourceforge was v0.4.1 from way back in 2016, and there wasn't a tarball release for the v0.4.2 source code despite this thread from 2019 having accepted George Prekas' changes adding partclone v0002 image format support (where he bumped the version to v0.4.2).
Two months ago, in response to my merge requests, the original author of this software (the user above named 'P') graciously offered me administrator privileges on this project to maintain it. He said "I've moved on to different endeavors and (as you can see) I haven't been paying much attention to the comings and goings in the past year" and suggested "I've made you an admin for partclone-utils so you are free to do as you wish with the project".
Despite getting admin access I haven't had a chance to start pushing partclone-utils forward with Rescuezilla-level development and support. Until now. In response to your request, I have uploaded tarball for partclone-utils v0.4.2, but I've also released v0.4.3 with the useful NBD timeout change from December 2019. For what it's worth, the tarballs were created using the following command: tar --exclude-vcs -cvzf partclone-utils-0.4.3.tar.gz -C partclone-utils .
I have also went back and tagged the git commits for all prior versions (which may be useful for packagers who want to get the code directly from git, rather than a tarball)
IMPORTANT: The v0.4.3 release does contain an issue around mounting NTFS images as captured in ticket #3. I haven't had a chance to debug this yet, but I will make time.
Also I should note here: as described Rescuezilla task #153, both partclone-utils and partclone-nbd are best used with uncompressed images (or images carefully compressed with custom settings like configuring a 16MB block size using xz). This is because compression formats like gzip and zstd aren't suitable for random access workloads, requiring decompressing the entire 100+GB archive to access a single byte and the end of the archive. To make partclone-utils and partclone-nbd widely usable and useful for all Clonezilla images, I am investigating solutions involving gzip-indexing.
Let me know if you have any issues!
Last edit: Rescuezilla 2021-02-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Thanks for the quick reply. Glad to see the project will be maintained. Being able to mount the disk images is such a handy feature.
Certainly tagging previous releases in git would be great for grabbing from source directly. I noticed the new tarballs differ from 0.4.1 releases where the sources are in a directory 'partclone-utils-0.4.1' and in the 0.4.2/0.4.3 they are not in a sub drectory.
Would it be possible to have this consistent across the releases?
Again, thanks for the response and glad to see this project being matained.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, as you have requested I have deleted the v0.4.2/v0.4.3 releases from yesterday and re-uploaded the archives with a subfolder, to be more consistent with past releases.
I was aware of the difference, but hoped to remove the pattern of using a subfolder because in my opinion it duplicates information that's already found in the tarball's filename, and its way more inconvenient (and therefore potentially more error prone) to create such a tarball using eg, tar --exclude-vcs -cvzf ../partclone-utils-0.4.3.tar.gz . because it involves moving the git sources folder to an empty folder and renaming the git source folder before creating the archive. (I'm open to suggestions/tips and tricks if this tarball construction process can be made simpler to avoid the folder renaming). Admittedly, there is great benefit in that typical end users won't get a "tarbomb"-like effect on their current working folder when unarchiving.
Last edit: Rescuezilla 2021-02-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
It is not a show stopper to have no subfolder. It just makes packaging a bit easier, at least for Alpine and perhaps others.
I figured tar can do this and apparently it can using --transform ver=0.4.3 tar cvf /tmp/partclone-utils-${ver}.tar --transform "s,^,partclone-utils-${ver}/," .
This will prepend a sub folder inside of the created tarball. It could be integrated into any scipts relating to tagging a release. I am suprised SF does not automate this. I took a quick check of their Wiki and found nothing obvious about automatically creating tarballs from tags.
Anyhow I think that would solve the problem of of the subfolder without changing much.
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool, that looks like a great command (and the version tag is programmatically extractable with git describe --tags). I will continue using the subfolder approach going forward and will encapsulate the command in a simple script tracked within the git repository. Just to re-iterate I have already re-uploaded v0.4.3 and v0.4.2 tarballs with the subfolders present.
Last edit: Rescuezilla 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I created with partclone, the images of three partitions of the same hard drive.
I can mount one of them using "imagemount" while with the other two I get the error in question:
sdaN.img: cannot verify: Invalid argumentI used the 0.4.1 version of partclone-utils compiled by me.
My system is Lubuntu 16.04 x86_64 with kernel 4.4.0-36-generic.
I can not remember partclone version.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
UPDATE:
I forgot to mention file system was "ext4" for all partitions.
I think this issue only occurs with earlier versions of partclone (the version of partclone with whom I created images was partclone-0.2.77 (contained in sysrescuecd 4.6.0)) because mounting an image created with partclone-0.2.86 (Lubuntu 16.04) I had no problems.
I will continue to do tests and in case, I will let you know.
There's a little utility that's built with the distribution of partclone-utils, partclone_imageinfo which dumps some cursory information about the file. Maybe if you could run that on the problematic file, that might provide some guidance.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
This is the output of that command on an image file NOT running:
However I have also the log generated by partclone during image creation:
This is the output of that command on an image file running:
and this is the log generated by partclone during image creation:
As you can see, images have been created with two different version of Partclone.
Sorry - I just found this in the moderation queue. The partclone_imageinfo fails with errno 14, EFAULT, which indicates that the used blocks count in the header doesn't match the actual count. This was a bug in previous versions of partclone which was remedied by using the "tolerant" flag in imagemount, -T. My recollection is that this was fixed before the version of partclone that you had said you used, but I could be wrong.
cannot verify: Invalid argument with partclone-utils version 0.4.1 on partclone version 0.3.11.
Did you try using -T with imagemount?
I have the same problem with partclone 0.3.11 and partclone-utils 0.4.1. Imagemount with or without -T gives the "cannot verify: Invalid argument" error. Testing the image with partclone.info and partclone.chkimg shows no errors, but partclone_imageinfo gives a "cannot verify image (error = 2)" message.
error = 2 is ENOENT - no such file or directory. Check your command line argument.
Yes, i checked the command line and when the file name is incorrect or non-existent, partclone_imageinfo gives a "cannot open image (error = 2)". With the correct file name, the message is "cannot verify image (error = 2)". Below is a little test using a VM.
Image created:
Getting image info and checking the image:
Getting image info with partclone_imageinfo with file name in the current directory and with the full path:
Trying to mount the image with imagemount:
Next test, i'll try a image created with partclone 0.2.89
UPDATE: With partclone 0.2.89 and partclone-utils 0.4.1 everything works well.
`root@PartedMagic:/media/sda1# partclone.ext4 -c -s /dev/sdb1 -o sdb1.img
Partclone v0.2.89 http://partclone.org
Starting to clone device (/dev/sdb1) to image (sdb1.img)
Reading Super Block
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%
Total Time: 00:00:01, 100.00% completed!
done!
File system: EXTFS
Device size: 8.6 GB = 2096896 Blocks
Space in use: 689.6 MB = 168371 Blocks
Free Space: 7.9 GB = 1928525 Blocks
Block size: 4096 Byte
Elapsed: 00:00:26, Remaining: 00:00:00, Completed: 100.00%, Rate: 1.59GB/min,
current block: 1606145, total block: 2096896, Complete: 100.00%
Total Time: 00:00:26, Ave. Rate: 1.6GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/sdb1) to the image (sdb1.img)
Cloned successfully.
root@PartedMagic:/media/sda1# partclone_imageinfo sdb1.img
sdb1.img: 2096896 blocks, 2096896 blocks scanned, 1928525 unset, 168371 set, 0 strange
sdb1.img: size is 692422164 bytes, blocks (4096 bytes) start at 2101064: 168371 blocks written
sdb1.img: read last block at end of file
sdb1.img: OK
root@PartedMagic:/media/sda1# modprobe nbd
root@PartedMagic:/media/sda1# imagemount -d /dev/nbd0 -f sdb1.img
root@PartedMagic:/media/sda1# mount /dev/nbd0 /mnt/loop
root@PartedMagic:/media/sda1# ls -l /mnt/loop
total 20
drwxr-xr-x 4 root root 4096 Jan 22 16:24 lib
drwx------ 2 root root 16384 Jan 22 16:22 lost+found`
The problem is that the latest versions of partclone use the image format version 0002. I have forked partclone-utils here https://github.com/prekageo/partclone-utils and added support for the image format version 0002.
Thanks, I accepted the merge request.
Could you create another tarball release for ease of packaging?
Thanks.
Hi Sean,
You are correct: the current latest partclone-utils tarball on Sourceforge was v0.4.1 from way back in 2016, and there wasn't a tarball release for the v0.4.2 source code despite this thread from 2019 having accepted George Prekas' changes adding partclone v0002 image format support (where he bumped the version to v0.4.2).
Two months ago, in response to my merge requests, the original author of this software (the user above named 'P') graciously offered me administrator privileges on this project to maintain it. He said "I've moved on to different endeavors and (as you can see) I haven't been paying much attention to the comings and goings in the past year" and suggested "I've made you an admin for partclone-utils so you are free to do as you wish with the project".
Despite getting admin access I haven't had a chance to start pushing partclone-utils forward with Rescuezilla-level development and support. Until now. In response to your request, I have uploaded tarball for partclone-utils v0.4.2, but I've also released v0.4.3 with the useful NBD timeout change from December 2019. For what it's worth, the tarballs were created using the following command:
tar --exclude-vcs -cvzf partclone-utils-0.4.3.tar.gz -C partclone-utils .I have also went back and tagged the git commits for all prior versions (which may be useful for packagers who want to get the code directly from git, rather than a tarball)
IMPORTANT: The v0.4.3 release does contain an issue around mounting NTFS images as captured in ticket #3. I haven't had a chance to debug this yet, but I will make time.
Also I should note here: as described Rescuezilla task #153, both partclone-utils and partclone-nbd are best used with uncompressed images (or images carefully compressed with custom settings like configuring a 16MB block size using xz). This is because compression formats like gzip and zstd aren't suitable for random access workloads, requiring decompressing the entire 100+GB archive to access a single byte and the end of the archive. To make partclone-utils and partclone-nbd widely usable and useful for all Clonezilla images, I am investigating solutions involving gzip-indexing.
Let me know if you have any issues!
Last edit: Rescuezilla 2021-02-01
Hello,
Thanks for the quick reply. Glad to see the project will be maintained. Being able to mount the disk images is such a handy feature.
Certainly tagging previous releases in git would be great for grabbing from source directly. I noticed the new tarballs differ from 0.4.1 releases where the sources are in a directory 'partclone-utils-0.4.1' and in the 0.4.2/0.4.3 they are not in a sub drectory.
Would it be possible to have this consistent across the releases?
Again, thanks for the response and glad to see this project being matained.
OK, as you have requested I have deleted the v0.4.2/v0.4.3 releases from yesterday and re-uploaded the archives with a subfolder, to be more consistent with past releases.
I was aware of the difference, but hoped to remove the pattern of using a subfolder because in my opinion it duplicates information that's already found in the tarball's filename, and its way more inconvenient (and therefore potentially more error prone) to create such a tarball using eg,
tar --exclude-vcs -cvzf ../partclone-utils-0.4.3.tar.gz .because it involves moving the git sources folder to an empty folder and renaming the git source folder before creating the archive. (I'm open to suggestions/tips and tricks if this tarball construction process can be made simpler to avoid the folder renaming). Admittedly, there is great benefit in that typical end users won't get a "tarbomb"-like effect on their current working folder when unarchiving.Last edit: Rescuezilla 2021-02-01
Hello,
It is not a show stopper to have no subfolder. It just makes packaging a bit easier, at least for Alpine and perhaps others.
I figured tar can do this and apparently it can using --transform
ver=0.4.3 tar cvf /tmp/partclone-utils-${ver}.tar --transform "s,^,partclone-utils-${ver}/," .This will prepend a sub folder inside of the created tarball. It could be integrated into any scipts relating to tagging a release. I am suprised SF does not automate this. I took a quick check of their Wiki and found nothing obvious about automatically creating tarballs from tags.
Anyhow I think that would solve the problem of of the subfolder without changing much.
Cool, that looks like a great command (and the version tag is programmatically extractable with
git describe --tags). I will continue using the subfolder approach going forward and will encapsulate the command in a simple script tracked within the git repository. Just to re-iterate I have already re-uploaded v0.4.3 and v0.4.2 tarballs with the subfolders present.Last edit: Rescuezilla 2021-02-02
Excellent thanks for that. I have submitted the merge request for the package update to Alpine Linux. Thanks!