cancel
Showing results for 
Search instead for 
Did you mean: 

Missing Drives in SSR (GUI) - after Update to SR2

M_N1
Level 2
For years I used "Ghost" for my backup and revovery without any problems. Now I started with SSR 2013 on Win 7 64bit. When I first needed a restore I have run into the bug, that SSR says, that a Backup from a BIOS machine cannot be installed on a UEFI machine (the source backup image is from the same machine as the destination machine is !). My system supports UEFI, but actually does not use it - so I searched for solutions and found a workaround here (bypass UEFI-check by using not the date selecion in the restore-gui) and the hint, that SR2 would solve that bug. So I updated to SR2 and the problems begun : 1.) Volume D (which was visible in the GUI before) was no longer shown in the GUI now So I searched for solutions here and tried : - FixInstall - delete history - restart services - shrink partition with stop/restart services - generate log-files with PartInfo and SmeDump (without a hint what causes my problem) - complete uninstall SSR 2013 (with data) and reinstall from new downloaded complete version of SSR 2013 SR2 nothing helped - and more worse : after the complete reinstall I get : 2.) all other external volumes which were visible before, are no longer visible yet - only C: and the hidden system-reserved partition remain visible Does anybody have an idea what can be done - or do I have to use another product - I have nerver seen such a buggy version !
1 ACCEPTED SOLUTION

Accepted Solutions

M_N1
Level 2
After the tasks above I generated new reports with PartInfo and SmeDump (\Program Files\Symantec\Symantec System Recovery\Utility) and compared them with the my fist ones, where the D was not shown in SSR Gui. I found in the old report (but not in the new one) : "MbrRegion.cpp(263) Function: MbrRegion::MbrRegion Error SME_ERROR_INVALID_SECTOR_POSITION (E0BB0183): The operation cannot be completed because sector position 0 is invalid." - I did not see that when looked in the first report before - my fault . So the cause for the D Partition to be invisible in SSR GUI was a partition start sector 0 ! Checking the partition again showed, that the D drive had no MBR (don't know how it was lost) - which is needed even if it is not a boot-drive. (the drive behaved completely normal and was accessible without problems in windows !). And the solution was : Extend the D partition with the unallocated space before it (result of my -now really temporary- steps above) and create a new MBR for the drive or drop D partition and recreate it, format D In both cases at the end you have a D partition for the volume with a start sector > 0. After that the Drive is visible for SSR Gui !!! The problem was not caused by SSR, OK but there should be an exception message with the infos the user needs to solve such problems ! Open question : why did I run into this problem after SR2 update and not before (Drive D was not changed before update) ? I hope these infos will help others with similar problems.

View solution in original post

2 REPLIES 2

M_N1
Level 2
Now I got an unsatisfying (i hope temporary) solution : What did not work for me was : 1. Start Diskmgmt.msc 2. Right click on the disks which SSR is not able to see 3. Shrink the volume by some nominal size (1GB-5GB) 4. Stop "Symantec System Recovery" and "SymTrackService" services 5. Start "Symantec System Recovery" Service 6. Open SSR console and see if the volumes are enumerated What worked for me was : 1. Start MiniTool PartitionWizard Home Edition (free) 2. Left click on the disk (D:) which SSR is not able to see 3. Move/Resize Partition : 100MB Unallocated Space BEFORE ( not AFTER ! D: partition) (creates 100MB unallocated space before the D: partition and xxx MB unallocated space after D: partition) 4. Extend Partition : Take free space from xxx MB unallocated (after D: partition) (to get the xxx MB unallocated space after D: partition back into D: partition) 5. no need for Stop/Restart of "Symantec System Recovery" and "SymTrackService" services 6. Open SSR console and go to backup ----> now the D: volume is visible in the gui again (and I hope it will stay) If I do not use unallocated space BEFORE but AFTER D: Partition the steps above do not show any effect. If the D: partition is visible gain in the gui and I extend the D: Partition with the unallocated space I have created before it, at that point, D: is disappearing again in the gui ! With the working steps above the D: volume looks similar as my C: volume which has a System-reserved 100 MB active & boot first partition and the System-(second) partition. Both volumes have a total size of 1863 GB (each). So what is happening here ? Do I have to keep 100 MB unallocated space before my D: partition to get SSR working or is there another satisfying solution ?

M_N1
Level 2
After the tasks above I generated new reports with PartInfo and SmeDump (\Program Files\Symantec\Symantec System Recovery\Utility) and compared them with the my fist ones, where the D was not shown in SSR Gui. I found in the old report (but not in the new one) : "MbrRegion.cpp(263) Function: MbrRegion::MbrRegion Error SME_ERROR_INVALID_SECTOR_POSITION (E0BB0183): The operation cannot be completed because sector position 0 is invalid." - I did not see that when looked in the first report before - my fault . So the cause for the D Partition to be invisible in SSR GUI was a partition start sector 0 ! Checking the partition again showed, that the D drive had no MBR (don't know how it was lost) - which is needed even if it is not a boot-drive. (the drive behaved completely normal and was accessible without problems in windows !). And the solution was : Extend the D partition with the unallocated space before it (result of my -now really temporary- steps above) and create a new MBR for the drive or drop D partition and recreate it, format D In both cases at the end you have a D partition for the volume with a start sector > 0. After that the Drive is visible for SSR Gui !!! The problem was not caused by SSR, OK but there should be an exception message with the infos the user needs to solve such problems ! Open question : why did I run into this problem after SR2 update and not before (Drive D was not changed before update) ? I hope these infos will help others with similar problems.