NTFS is inconsistent

[tekmans]

Hello

i'm using clonezille alternative in lastest version 20180119-artful

i'm trying to restaure an image and it looks ok

*****************************************************.
Restoring partition /dev/sda1...
*****************************************************.
...

done.

*****************************************************.
Restoring partition /dev/sda2...
*****************************************************.
...

done.
*****************************************************.
Now tuning the file system size on partition /dev/sda1 to fit the partition size...
Running: ocs-resize-part --ntfsfix --batch /dev/sda1
**Mounting volume... FAILED** <----------------------------------------
Attempting to correct errors... FAILED
Checking for self-located MFT segment... OK
ntfsresize -f -f /dev/sda1
ntfsresize v2016.2.22AR.2 (libntfs-3g)
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0  usa_count: 0: Invalid argument
Record 0 has no FILE magic (0x0)
Failed to load $MFT: Input/output error
ERROR(5): Opening '/dev/sda1' as NTFS failed: Input/output error
NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
The usage of the /f parameter is very IMPORTANT! No modification was
and will be made to NTFS by this software until it gets repaired.`

Do you have already seen something similar ?

the corresponding logs complete logs : https://paste.debian.net/1011149/

PS it was working well with previous version ( 20170829-zesty)

Thx

[neoclust]

Seems like the problem is with the MBR partition

[tekmans]

Is really strange, mbr looks OK

# parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 161GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  524MB   523MB   primary  ntfs         boot
 2      524MB   72.2GB  71.7GB  primary  ntfs
 3      72.2GB  120GB   47.8GB  primary  ntfs

# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR;

[tekmans]

Do you have an update ?

[porsager]

Hi. I'm having the same issue trying with clonezilla-live-20180329-artful-amd64

It works fine with clonezilla-live-2.5.2-31-amd64, but I also can't use that because there's a random issue on my hardware with that Linux kernel resulting in soft lockups (happens about 3% of the time).

I've been digging through the changelogs between clonezilla-live-2.5.2-31-amd64 and 20180119-artful, but I've been unable to find anything that would seem to relate to that.

An important note is maybe that the image I'm trying to restore was created with partclone 0.2.91, but as far as i can tell 0.3.11 shouldn't have problems with that.

@tekmans did you figure out anything?

[porsager]

Ok, I've narrowed this down to be between 2.5.2-31 and 2.5.3-1.

Partclone was updated to 0.3.6. //NOTE// New image format is used in this release.

My best guess is that it has something to do with partclone 0.2.91 > 0.3.6. I'll try to to create an issue in the partclone repo as well.

[porsager]

I've tried a bit more, and I've found that using partclone 0.2.91 with the latest stable clonezilla clonezilla-live-2.5.5-38-amd64 solves the issue.

[stevenshiau]

Are you able to reproduce this issue in a virtual machine like virtualbox or vmware? If so, please share that virtual disk so that we can try to reproduce this issue here. So far the tests here work without any issue like you mentioned.

Steven

[porsager]

Hi Steven.. Sorry for the late reply. I haven't had time to try it out in a virtual machine, and don't know when it's possible for me.

The tests you run, are they using partclone 0.3.6 to restore an image made with 0.2.x ?

[stevenshiau]

Yes, the tests we have are using partclone 0.3.6 to restore those images made with 0.2.x.

Steven