New
#11
Just a post-script here...
(1) I have been in touch with Macrium on this issue over the past few days. Despite the fact that I was using the "unsupported" free version of their product, their "parental pride" clearly motivated them to look into the bug and fix it... since it clearly may also have involved their non-free versions. Very impressed with their attitude, and prompt attention to this matter (which was a TOTAL DISASTER for me when it occurred, although I was eventually able to overcome 100% of the "damage" with ZERO loss of data... a true miracle).
Anyway, today I received an email from them advising that they'd found what they believed was the problem with that Linux version of the standalone program, and could I give it another try (at least up to the point of ensuring that the program's confirmation screen showed the correct information, even if I didn't go further with the true restore).
There email (and "release notes") mentioned that the correction dealt with disk signatures, and potential mis-handling by the Linux program under certain circumstances.
(2) I opened the installed Win7 program (build 4118) and it automatically detected that there was a new version available for download (4168). I installed this update, and then re-built the Linux standalone boot CD. Then I re-ran the preliminary steps of a restore of my O partition from that 11/20 MRIMG backup file using the new 4168 Linux CD. And sure enough, the "target drive" was now correctly described as the proper drive, not the incorrect drive. So I assume it would have now worked properly if I'd let it actually do the restore.
And thus I would conclude that their "fix" to the Linux program has actually accomplished what they wanted to fix.
(3) However their mention of "disk signature" got me to thinking. I thought back to what had happened this past weekend, when apparently using the 4118 Linux program to restore my O partition had also forced a duplicate disk signature to the target drive, which had then caused a "signature collision" when booting Win7, when had then caused that drive to be placed OFFLINE by Windows.
It was only when I used DISKPART, and ONLINE DISK x to bring the drive back online that it came back... somehow. So obviously there now was a unique signature for that drive, and no more duplicate "collision".
Well, with all of this running around in my head I decided to do a little investigation... of my current disk signatures, and also of what the Reflect MRIMG file looks like inside of it.
I then looked at my three hard drives, using DISKPART. They are as follows (I'll refer to them by their label abbreviations, for clarity):
Disk 0 WDC320 signature 0005420E partition O lives hereNote that the E partition is mentioned because (a) that's where the output target folder lives which holds the MRIMG backup files, and (b) it is that drive's signature 83188EEB which shows up to be super-crucial to this bug.
Disk 1 WDC150 signature 48F8E5E0 partition C lives here
Disk 2 MAT140 signature 83188EEB partition E lives here
Also, I'm sure that the signature of 0005420E for Disk 0 is NOT what it was back on 11/20 when my original MRIMG backup was created. It had to be something unique for sure, but it probably wasn't this. I believe the current value of 0005420E was newly assigned this weekend by the DISKPART command, ONLINE DISK x, which must have also performed a UNIQUEID DISK command inside of it in order to assign a new unique signature and thus resolve the "signature collision" and thus be able to bring the drive back online.
Anyway, while the 4118 Linux program may have been a "victim" and done the wrong thing, I am now convinced (and have communicated to Macrium) that the real problem was in the MRIMG file itself produced back on 11/20 by the 4118 Win7 version of the program.
The real 4118 problem is that the signature of my Disk 0 (where the O partition lives) was NOT written to the output MRIMG file. Instead, the signature of my Disk 2 (where the E partition lives) was written out. The second partition (C) in the MRIMG did get the correct signature for Disk 1 (where the C partition lives). But that first partition O, which was then tried to restore... it has the WRONG signature in the MRIMG file, namely that of Disk 2 instead of Disk 0.
(4) Having a very strong hunch about all of this, I then produced a new MRIMG file tonight but using the newly patched 4168 version of Reflect, again backing up O and C just as I'd done on 11/20 with the original flawed 4118 version of the program. So now I had two MRIMG files to examine, one from 11/20 produced by 4118 and the second from 12/7 produced by 4168.
I then began a restore (using the Win7 version so that I could take screenshots, even though I know I couldn't restore O except with standalone Linux/WinPE versions).
As you can see from the following screenshots, my suspicion is borne out by the evidence. And while Macrium certainly fixed the 4118 Linux program which had what I now feel to be a "minor" flaw, it really was a "victim" in the story. The real problem was, just as I suspected, with the 4118 Win7 version of Reflect which actually produced a flawed MRIMG file in that the first partition backed up had the incorrect disk signature (which apparently was the signature of the target folder's drive that would receive the MRIMG output file).
In fact, even the new 4168 Win7 Reflect, when starting the restore of O from the flawed 11/20 MRIMG file produced by 4118 Win7 Reflect, actually still defaults to the incorrect target drive to receive the restored partition... just as the original flawed 4118 Linux program did. So Macrium may have fixed restore in the 4168 Linux program, but they don't seem to have fixed what looks like the same problem in the Win7/WinPE version of the program... although again, they're "victims" too.
The real "culprit" is the flawed MRIMG file produced by 4118 Win7 Reflect, which incorrectly put the wrong disk signature in the first partition written out to the MRIMG file. And THAT is what causes all of the problems and confusion on restore... either by picking the wrong target drive by default, or by restoring a "duplicate signature" in the MBR of the drive receiving the restore partition.
The damage (i.e. "signature collision") comes from restoring an incorrect signature to the target drive, which happens to be the signature of the MRIMG drive for the first partition contained within that MRIMG file.
Here is the setup configuration for the 12/7 backup using the fixed 4168 Win7 Reflect. Notice the input O partition on Disk 0 (0005420E), input C partition on Disk 1 (48F8E5E0), and output target on E partition (83188EEB).
Looking at the resulting MRIMG as if I wanted to restore the O partition, note that the first partition file contained within it is correctly from Disk 0, and has the correct signature of 0005420E.
Also, if I go to the next step of the restore note that the correct source and target drives are properly matched, namely Disk 0 with the signature of 0005420E which is genuinely where the O partition lived when the MRIMG was taken, and also by default where I want to restore it.
Now, in contrast, look at the same analysis (still using the new "fixed" 4168 version of Win7 Reflect) but reading the original flawed 11/20 MRIMG file which produced the disaster last weekend.
First, notice that the signature for the Disk 0 drive containing O partition is incorrect. It is not whatever it was back on 11/20 (not 0005420E I'm certain, but also 100% guaranteed absolutely not to be 83188EEB either)... namely the grossly incorrect 83188EEB! This is really the "giant clue" to the impending disaster.
And, when I proceed to the confirmation screen, sure enough even this theoretically "fixed" 4168 Win7 version (though clearly Macrium did NOT fix this program as they did seem to fix the Linux version) picks the wrong default target drive (i.e. my Disk 2, with signature 83188EEB) instead of the proper Disk 0 where the O partition actually lives (and lived, even back on 11/20).
If I let the restore proceed, the O partition which should go to Disk 0 will actually go to Disk 2... clearly not what I want (but what I got over the weekend). And if I change the target drive to correctly point to Disk 0 it will probably replace the MBR signature with 83188EEB (as it mistakenly was on the MRIMG input file), thus producing a "signature collision" since now Disk 0 and Disk 2 will have the same signatures. One of the drives will be taken offline by Windows.
And all of this is now obviously because of the wrong 83188EEB signature was mistakenly written for the O partition by the 4118 flawed Win7 Reflect on 11/20 when that MRIMG file was created.
It will cause problems because of that wrong signature in the MRIMG for the drive containing the O partition. Period. I'm now about to delete it.
Thankfully, the corrected 4168 version of the Win7 Reflect has fixed this problem (as proven by my screenshots above), in that now the proper signature of the first archived partition's hard drive is correctly written out to the MRIMG file. Thus there will NEVER be any problem for its restore, no matter what program is used to restore it (including an older 4118 version).
Again, the problem really was with the 4118 Win7 Reflect which wrote the incorrect signature out for that first partition in the MRIMG file.
Quote