Silent failure of imagemount

nyanpasu64 — Tue, 21 Jun 2022 08:28:46 -0000

I get the same issue on Arch Linux, partclone-utils fails silently unless I pass -D in which case it fails with an error message. I found that errors like /dev/ndb0: cannot connect: No such file or directory show up in journalctl. I think there are two problems: error messages are not shown to the user and don't set the return code to a nonzero value (they're only logged), and either imagemount is broken or I'm calling it incorrectly.

Efficiently imagemount a very large xz-compressed partclone image - without decompressing whole xz file?

Rescuezilla — Mon, 25 Apr 2022 06:42:19 -0000

I've had success with this tool I wrote called lzopfs, similar to archivemount. You get best results with parallel xz compression (pixz).

Silent failure of imagemount

Rescuezilla — Sun, 02 Jan 2022 17:48:25 -0000

Hi Amiga Lemming,

As a temporary workaround, try following the guide I've written here which documents how to use the partclone-nbd tool (rather than this partclone-utils tool) in your standalone Linux environment.

You'll of course first need to download and build the partclone-nbd source code (from here), but since you've already appear to have done this for partclone-utils it shouldn't be much of a problem.

Hopefully that helps.

The Rescuezilla graphical frontend will always provide the easiest way to mount images, and the next version should provide a simple high-level command-line interface to deal with any random partclone-based image without having to delve into the low-level NBD details.

Error: ./sdaN.img: cannot verify: Invalid argument

Sean — Tue, 02 Feb 2021 02:25:14 -0000

Excellent thanks for that. I have submitted the merge request for the package update to Alpine Linux. Thanks!

Error: ./sdaN.img: cannot verify: Invalid argument

Rescuezilla — Tue, 02 Feb 2021 01:27:55 -0000

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 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.

Error: ./sdaN.img: cannot verify: Invalid argument

Sean — Tue, 02 Feb 2021 00:49:08 -0000

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.

Error: ./sdaN.img: cannot verify: Invalid argument

Rescuezilla — Mon, 01 Feb 2021 23:26:13 -0000

OK, as you have suggested 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.

Error: ./sdaN.img: cannot verify: Invalid argument

Sean — Mon, 01 Feb 2021 18:42:46 -0000

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.

Error: ./sdaN.img: cannot verify: Invalid argument

Rescuezilla — Mon, 01 Feb 2021 10:00:11 -0000

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 until now I haven't had a chance to start pushing partclone-utils forward with Rescuezilla-level development and support. 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!

Error: ./sdaN.img: cannot verify: Invalid argument

Sean — Mon, 01 Feb 2021 05:36:37 -0000

Could you create another tarball release for ease of packaging?

Thanks.

Recent posts to Discussion

Silent failure of imagemount

Efficiently imagemount a very large xz-compressed partclone image - without decompressing whole xz file?

Silent failure of imagemount

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument

Error: ./sdaN.img: cannot verify: Invalid argument