Skip to main content

TI2020 "unable to lock ......"

Thread needs solution

Have three DVD-s for booting TI:

1.  MVP generated with added driver for ocz revodrive, generated from MVP-site a year ago.

2. Acronis 2020 TI freshly generated from the windows-installed Acronis 2020, added driver for ocz revodrive.

3. Acronis 2020 TI without driver for the Revo,  burned from Acronis site a year ago..

 

Booting and runing no. 3, no problem at all with hdd source to hdd target.

This TI presents a menu at start for selection of TI 32 og TI 64 bit, as well as other options.

One should select choice via F10 and arrows.  Selecting always TI 64 bit.

 

Booting and running no. 2,  it goes directly into menu for "Create new disk",  "clone", etc.

Seelctiing and exectuting  "add new disk" for target hdd, then selecting source.

Very often: Unable to lock ....".  Trying again and again, and often it will continue ok..

 

Booting and running no 1.,  selecting hdd for source and the revodrive for target.

Else same procedure as under no 2.  Also same result, "unable to lock..."

 

question:

Is the revodrive-driver to blame for the "unable to lock" ?

And why the different startup behaviour no 3 vs the other two ?

Any work arounds ?

 

regards

erik

 

 

 

 

 

 

 

0 Users found this helpful

Erik, an interesting study on this known scenario of the 'unable to lock the drive' when using rescue media!  I am not aware that any specific device drivers are involved in whether the locked status can be circumvented or not?

Like you, I have found that retrying the operation multiple times has been successful at times, and other times, I have resorted to initialising the destination drive before starting the PC booting from rescue media, so as to ensure no locks or lock flags remain.

The common explanation for the locks is because the PC has got Windows Fast Start and/or Hibernation enabled, and was not fully shutdown, hence leaving the file-system in an uncertain state and locked.

There is a good explanation of this state in webpage: HDD with Windows boot locked because of hibernation flag in the only answer given.

I agree that it is strange that you are seeing somewhat consistent behaviour for the 3 different copies of rescue media but have no other explanation.

It is strange that Acronis knows that the user is wanting to wipe the destination drive when doing a disk recovery or using the Add new disk tool, yet doesn't offer an option to override the lock regardless given the intent is to reinitialise the drive!

Thanks for most interesting info re "unable to lock....".

Tried to disable hibernation, found info in the link you stated,

used download of "disable_hibernation.reg",  executed ok.

Shutdown, restart, booted the acronis dvd, hoped, but no, still "uable to lock".

So I guess wre are stuck with this problem (or maybe not ??)

regards

erik

 

 

 

erik,

Another issue that arises causing the unable to lock the disk error is that of Windows update.  There are times when Windows update does not successfully install a pending update completely.  This can cause an unstable state for the PC thus the unable to lock message.

One way of addressing that issue is to boot the PC into Safe Mode then at the sign in screen click on the poser button on the lower right screen and select Restart.  If you get a warning that other users may lose data select restart anyway.

Once you have done this boot to the recovery media and try again.

Below is a link which covers how to boot into Safe Mode:

Safe Mode

SOLVED (maybe ?).

Booted TI 2020 rescue media (DVD).

Always selecting "add new disk" for the target before proceeding with clone.

Then selecting "clone"

Stepping through the selections, stopping at selection for "manual" and "automatic".

If fast proceed with further selections, the "unable to lock" often pops up.

BUT: if waiting for a long time (tried 1-2 min. maybe could be less) before "next" with manual

selection, it seems the "unlock" will NOT pop up !!!

Could it be some timing problem here in TI ?

regards

erik

 

 

Timing could very well play a part in this issue Erik..!