#3 imagemount v0.4.2 does not work for all NTFS, many ext4 filesystems

[Rescuezilla]

Hi,

As part of my work on the Rescuezilla "Image Explorer" graphical frontend, I am evaluating, consolidating and improving partclone-util's imagemount tool.

As best I can tell, due to a bug in partclone-utils it's not actually possible to mount an NTFS filesystem for both partclone v1 images, and partclone v2 images. The imagemount command returns success, but trying to mount the /dev/nbd1 device produces an error such as:

Launched in daemon mode: All logging output being written to the system log.
Failed to read last sector (4030): 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/nbd1': Invalid argument
The device '/dev/nbd1' 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?
mount reported error

There's a similar bug affecting ext4 filesystems (cannot find superblock). The FAT and F2FS filesystems appear to mount fine though.

In Merge Request #5 I have improved the test.sh file to make these bugs trivially verifiable.

I will try and investigate and resolve this issue as best I can, but I also raise an issue with prekageo (the author of imagemount's partclone image v2 support) as he might have some insights.

I have some major plans for partclone-utils, so hopefully we can be communicative as I do my best to provide merge requests for partclone-utils going forward.

Regards,

Shasheen Ediriweera

Developer of Rescuezilla

[Anonymous]

Hi Shasheen,

Confirmed, partclone.ntfs doesn’t include the last block, on restore it is missing, too. (0xAA55). May create issues when restored to a preformatted ext4 partition.

And I can confirm the “many ext4” issues, but again that’s not imagemount’s problem.

Imagemount will successfully attach ext4-images to nbd-devices, these devices can be dd’ed back to img-files and mounted.
But depending on the folder (???) where the attached image-file is stored, e.g. Mint (19.3) can or can not mount these devices directly (error is with read or write superblock, don’t know what that means).
Again, the dd’ed copy of that nbd-device can be mounted, so I think it’s a problem with Linux’ mount.
For details see my posting: https://forums.linuxmint.com/viewtopic.php?p=1891126#p1891126
Sorry, noob here, don’t know how to proceed.

Regards,
Sancho

(EDIT by Rescuezilla: Fixed link the point to correct forum thread after double-checking with this user via an email conversation)

[P.Rouleau]

Hummm, I made this pull request a while ago, 🙄
https://github.com/Thomas-Tsai/partclone/pull/54

I have messaged the Thomas to try to get it merged in the current partclone code.

[Rescuezilla]

P.Rouleau wrote a comment relevant to this issue on Merge Request #8:

One thing I want to try to handle in partclone-utils is to implement a workaround for the missing last sector in NTFS image made by partclone. I still have to play more with the tool to clarify if it is a blocker or just an annoying warning.

My response: I don't believe the missing final sector is a blocker that requires changes to partclone. My assertion can be verified by using partclone to restoring the NTFS image to a block device (or a normal file using the --restore_raw_fileargument). You can then use the standard mount command to access files. Though can't remember if you are required to run a tool like ntfsfix before you can mount the filesystem after restoring.

As you're aware, partclone-utils is heavily reliant on the NBD (Network Block Device) interface. As far as I understand the NBD interface makes logically reading and writing arbitrary bytes very easy, the changes are efficiently overlaid, (optionally?) with a concept called "change files" containing the diff that can be written out to disk.

To solve this issue, what may be required is changes to the imagemount application to modify the NBD block device with whatever byte manipulation that partclone does doing during a standard restore operation. Hopefully any bytes that need to change will live in RAM, or if written out to a changefile one that at least lives in /tmp.

[P.Rouleau]

On Fri, Feb 19, 2021 at 9:33 PM Rescuezilla rescuezilla@users.sourceforge.net wrote:

P.Rouleau wrote
https://sourceforge.net/p/partclone-utils/git/merge-requests/8/#f6d4 a
comment relevant to this issue on Merge Request #8:

One thing I want to try to handle in partclone-utils is to implement a
workaround for the missing last sector in NTFS image made by partclone. I
still have to play more with the tool to clarify if it is a blocker or just
an annoying warning.

My response: I don't believe the missing last sector is a blocker that
requires changes to partclone. My assertion can be verified by using
partclone to restoring the NTFS image to a block device (or a normal file
using the --restore_raw_fileargument). You can then use the standard
mount command to access files. Though can't remember if you are required to
run a tool like ntfsfix before you can mount the filesystem after a
restoring.

Ha! I forgot the existence of ntfsfix. I will check what it does exactly.
Most of the time, when I restore, I restore in the same partition. So even
if the last sector was not restored, the one already there does the job. I
will also check if Clonezilla uses ntfsfix after restoring an NTFS image.

To solve this issue, what may be required is changes to the imagemount
application to modify the NBD block device with whatever byte manipulation
that partclone does doing during a standard restore operation. Hopefully
any bytes that need to change will live in RAM, or if written out to a
changefile one that at least lives in /tmp.

That's what I want to implement, with some logic that checks the version
used to make the image. If it is a version known to not include the latest
sector, show a warning; otherwise, show an error. I will implement that in
partclone_imageinfo first and have to think of a way to implement some
tests about that.

Regards,
P. Rouleau

(edited to fix formatting issues caused by replying from gmail)

[Rescuezilla]

That's what I want to implement, with some logic that checks the version
used to make the image. If it is a version known to not include the latest
sector, show a warning; otherwise, show an error. I will implement that in
partclone_imageinfo first and have to think of a way to implement some
tests about that.

OK cool, modifying partclone-util's partclone_imageinfo.c to print an error message when a bad file is detected seems like a reasonable immediate path forward.

(By the way, your email reply didn't render correctly in Sourceforge for some reason: the quoting is all wrong, making it very difficult to read your message. You might want to edit your post to resolve this.)