After I cloned my boot partition....
The cloning went very well and the computer now boots from the SSD.
However the HD partition from which the computer previously booted now
shows as "unformated". Is this normal or did I do something wrong?
The cloning went very well and the computer now boots from the SSD.
However the HD partition from which the computer previously booted now
shows as "unformated". Is this normal or did I do something wrong?
Comments
Please give us the screenshot of the Windows disk manager page.
You cloned from HDD to SSD. Desktop or laptop? How exactly did you do that? Cloning will never change the source drive.
Is it possible that you use the HDD now with a to long usb cable? I did that once and the drive became corrupt that way. Anyway, check all the cables and connections.
Johnny, both the HDD and the SSD are internal, no USB involved. Cloning was done with them both being installed internally. Both drives remain internally with the same cabling as when I did the cloning. Note that I cloned the boot partition on a HDD to be the only thing on the SSD.
Admin, here is the screen shot of the three drives on my computer. The former boot partition is now identified as "I:" and is shown as RAW.
and urgently I suggest do a partition backup of your new SSD to an .adi
your new C: has 62.75GB used, but your old partition where Windows was, I:, has just 58.59GB in total. please explain this.
It is strange that your old partition, I:, where Windows was is at the high end of the disk, this is unusual.
What if you disconnect the SSD and try to boot again from the original HDD? Does that work? I wonder has the HDD really become corrupt or does it only look/show corrupt?
Please try to boot from the disk0 to see it it is ok to boot.
By the way, do you encrypt it?
Peter: I did the clone a while ago so the size difference is probably due to installations and/or updates after that; I have just posted this question now since I had the time to do so. I too found the location of partition I: odd as well but just wrote it off as something Windows did because of the drive letter.
Johnnyboy: I have not tried booting from the original HDD without the SSD being connected. The other partitions on that HDD are fine; it is just the former C [boot partition] that is showing as RAW.
When I try looking at the former boot partition using Windows Explorer or any other programs it is always declared to be unformatted.
Admin: Nothing on my computer is encrypted.
I will try pulling the cable from the SSD and see if the computer boots from the old boot partition; I suspect it will not since the computer has not complained about confusion arising from having two bootable partitions/drives. But that experiment will probably be delayed until the weekend since I will have to extract the computer from where it is housed, disconnect all the cables, and open the housing.
Admin: From your responses up to now, I get the impression that the old boot partition should not have been changed in any way when I cloned that partition to the SSD. Is this correct?
below is not an excuse, but by repair attempts the factual reason could be found.
I faintly remember a post of january where user reported that the wrong disk was targeted by clone.
I also remember that OKR clears recovery partitions that it does not love.
Windows does not install the OS partition there (but.. perhaps it was installed on a non-empty disk), and drive letters do not matter. Drive letter was C: when it was the OS partition. It is I: now. Possibly there have been operations before, with other tools, that made it "too difficult" for I-dont-know-what.
It is also noteworthy that system and boot are one same partition. Perhaps... something cleared the other, former system partition?
a) maybe, Google helps: windows fix damaged ntfs
I found fsutil.exe from Windows
I found ntfs.com
b) The idea targeted above is, that the partition boot sector contains valuable information about NTFS, like where $MFT is and the like (also called BIOS parameter block and googled).
https://technet.microsoft.com/en-us/library/cc781134(v=ws.10).aspx
https://en.wikipedia.org/wiki/BIOS_parameter_block
c) on a MBR disk you could try to set the partition type to 0x07 (NTFS) and hope. On a GPT disk I did not find equivalent.
I do not believe diskpart will help, but you could try and see the output
diskpart
list disk
select disk #
list partition
select partition #
detail partition
detail volume
exit
Actually, if you just do the clone, the source disk will not be affected.
Admin: Due to life intervening, I was not able to post the results of trying to boot my computer with the SSD disconnected.
The computer hung with the BIOS saying "loading operating system". I waited for a while to see if anything would happen and the message just stayed there. I reconnected the SSD and the system booted normally.
I did the clone using version 3.1 if that suggests any possible reasons for the former boot partition becoming raw.
a similar older thread here www.aomeitech.com/forum/discussion/2652/
Peter: I had a look at that thread and it related to drive letter assignment. The issue here is that the original drive that was cloned was obliterated and became raw, unformated. The drive letter assignment to the now RAW partition was secondary and of no real consequence. Thanks for the suggestion anyhow.
the report in that thread was: an error message in PA is about drive letter, insofar only you are right. But the reason for this was cleared partition, see image in that thread. http://prntscr.com/afit7a
Peter: I had a closer look at the thread and there is a similarity insofar as the partitions in both cases became raw [my partition is identified as raw and did not change in size while the ones in the other thread are identified as unallocated and free space and partitions were merged in the process].
The issues in the other thread arose from using Partition Assistant, while mine happened with a cloning process using Backupper. The unfortunate thing is that there was no resolution in the other thread as to what might have been the cause because [I assume] the poster decided to delete PA.
Peter's post #4 above gave me the idea to see if a recovery program could dredge out anything from the former boot, now RAW, partition. Of the programs I have, only MiniTool Recovery was able to look into the partition. Even more curious was that while the boot partition prior to the cloning had about 45 GB, the program only found 677 MB of data all of which was identified as RAW files [raw is what the ! before the file name means]; I should also add that while MiniTool was scanning it never found an NTFS or a FAT boot record. Whether this is a shortcoming of MiniTool I do not know.
I thought I would post the MiniTool results with this post to see if it wcould help identify what may have happened with a view to fixing the issue so others are not affected by it.
One consequence of this is: do not clone, do backup and restore. And yes before restoring do a replicate of the backup image files.
Backup of whole partitions and even more of the boot environment is a harsh business. Recently I did a "Windows Create System Image" restore, it complained with "parameter error" and on the second attempt it cleared the data partition
to raw. I did have Aomei backupper backups, they restored C: and 
, but I had to re-create the ESP Efi System Partition and WinRE partition. bcdboot command made it work. WinRE I did not yet know how to repair but in between I learned. The software I used before Aomei would have lost C: (that's why I didn't use), and "Windows Create System Image" never failed before. Harsh business.
And yes one has to know the boot process, the details around C: and it is not easily documented. There isn't a lot to type, it does it automatically, and a few caveats to see.
What is the result of fsutil.exe, and of ntfs.com? see my #8
No, it is not the reason. But hope you can install the latest version 3.2.And also we will release the new version quickly, please wait. It solves the bugs and new functionalities.
Peter no I have not tried fsutil and ntfs......I want to read more to be sure that I do not cause more problems.
The reason I used clone rather than backup and restore was because I was going from a boot partition on a HDD to boot from an SSD which was not in the system previously. I did not want to have problems with Windows complaining about changed hardware; my understanding was that making the change I did would cause Windows to complain. Whether my logic/information was sound I do not know.
Having reflected on the results from MiniTool it seems that the cloning behaved somewhat like what Windows does when you "cut" or "move" rather than "copy" files: the files that were transfered to the SSD were deleted from the HDD.
Admin: Am I correct in understanding from what you said in #17 that my situation was caused by a bug in version 3.1 of BackUpper?
I am not trying to blame anyone because we all know that even huge companies like Micro$oft have bugs in their software. If it is a bug and being fixed that is all that is important as far as I am concerned. Will the bug be squashed in version 3.3?
Homer, a clone is just the same as a backup and a restore. All in one step, that's the idea. In theory it does nothing change to the source. Another wise advice is to disconnect the HD, to have just one bootable disk in the system (need to give the source? here in the chapter Recommendations) Windows by itself would not complain about a changed harddisk, it would just adapt, and no new drivers are needed it is SATA storage. The boot process (Windows Boot Manager) would complain a bit but self-repair usually. Your computer is BIOS it would not complain.
PS I did replace a few disks in the past and I never did a clone. I always did a backup then a restore. The source disk served as an extra backup, and as it was removed it could not be damaged, and it is easy to back out. This protects against a miriad of technical and human factors.
PSPS you should really try fsutil.exe: disconnect the SSD, connect the HD only, boot from any bootable media, windows command shell, learn what drive letter is the raw partition, and run fsutil.exe on it. fsutil is on any bootable media.
"Admin: Am I correct in understanding from what you said in #17 that my situation was caused by a bug in version 3.1 of BackUpper?"
Thanks for your understanding first. No, your source system became the RAW, it is not the BUG in the version 3.1. Because we do not encounter it before. We ask you send us the LOG before so that we need it to find the problem. But, finally, you fix the problem and the system is al ok for you now.
I'm no expert by far but I guess that you restarted your system with the 2 disks after cloning, which means that you had 2 os and that Windows deactivated the 2nd one, i.e. the hd source but kept the other partitions. Had you taken out your hard disk before startup you might not have encountered this problem.