Lenovo R500, problem z partycją recovery

[iksigrek]

Mam problem z odzyskaniem systemu na tym lapku. Przy starcie, po wciśnięciu ThinkVantage i F11 dostaję komunikat o tym, że uruchomienie systemu nie powiodło się, a przyczyną może być ostatnia zmiana sprzętu lub oprogramowania... Stan 0xc000000f ... "Nie można uruchomić pozycji rozruchu, ponieważ wymagane urządzenie jest niedostępne".

Oprócz partycji systemowej są tutaj:

SYSTEM_DRV
Lenovo_Recovery

aktywowanie partycji SYSTEM_DRV z bootmgr nie daje żadnego efektu (przełącza się za drugim restartem na systemową). Ogólnie sam system się odpala, ale jest problem z ruszeniem Dosowego Recovery. Gdzieś znalazłem info, że po zainstalowaniu Rescue and Recovery w Windowsie, ustawi się prawidłowo MBR i powinna działać kombinacja ThinkVantage + f11, ale i po instalacji nic się nie zmienia. Na wymienionych partycjach powyżej użyłem chkdsk, ale też nie pomogło. Smart Ok.

 

Jak wystartować soft przywracający jeśli widzę partycję odtwarzania z zewnętrznego programu ?

[maggreg]

Przejrzyj ten temat:

https://www.fixitpc.pl/topic/1841-lenovo-y550-one-key-recovery-windows-7/?hl=lenovo

 

Wypróbuj porady tam podane i sformułuj ew. pytania uzupełniające.

 

pzdr

[iksigrek]

--Temat nie bardzo mi pomógł, mam inaczej rozmieszczone pliki.

--Próbowałem grzebać w tablicy allokacji na dysku pierwszym SYSTEM_DRV (1,17 GB) i czwartym Lenovo_Recovery (9,77 GB). Na pierwszym jest bootmgr. Próbowałem różnych ustawień, m.in id na 0x12 i bootowanie (80). Partycja aktywna z bootmgr'em recovery zaczyna się na 2048. Próbowałem różnego softu, np. plop boota, PTEDITa i innych partycjonujących.
--brak również wirusów na dyskach i w sektorach rozruchowych (sprawdzane KasRD 10)

Poniżej tablica alokacji i listing roota dysków. Niestety nie mam uprawnień do zamieszczenia pełnego listingu katalogów w zip na tym forum, więc wrzucam przez senspace: http://www.sendspace.pl/file/8944a1be365a5fc7c95ca33

 

[maggreg]

Daj pełny listing BCD (z /enum all).

Katalog "tvtos" to twoje dzieło czy był fabrycznie?

 

Partycja recovery nie zawiera żadnych plików umożliwiających start systemu live więc przestawianie botowania nic nie da.

Wygląda natomiast na to, że reco jest upakowane w czystym pliku wim tylko nazwy nie są jednoznaczne, nie wiem czy mają one służyć do utworzenia konfiguracji naprawczej czy odzyskania docelowego systemu.

 

pzdr

[iksigrek]

tvtos z winpe.wim w środku było tam cały czas. Z tego co się orientuję, nic nie było nigdy mieszane na tych partycjach poza ew. usunięciem ich liter dysków z windows, żeby nikt tam nie nabroił. Wydaje mi się, że partycja SYSTEM_DRV to partycja bootowalna z systemem odzyskującym i ona jakoś odnosiła się do recovery. System był dawno temu odtwarany z OKR przez F11, ale nie mam pojęcia, kiedy to przestało działać i po jakim zdarzeniu.

 

Po przypisaniu litery mogę zrobić bcdedit dla SYSTEM_DRV bcdF.txt, ale Lenovo_Recovery jest puste ("Nie można otworzyć magazynu danych konfiguracji rozruchu...")

 

ahh... zapomniałęm dodać, o ile to coś zmienia, że po przestawieniu na boot i id 12 dla partycji od sektora 2048, zamiast błędu 0x000000f mam Stan 0xc0000225...

[maggreg]

Ok
W BCD jest zdefiniowany custom action uruchamiający pe z tvtos.
Jeżeli domyślny key nie działa to można go zmienić (visual BCD editor radzi sobie fajnie z custom actions -http://www.boyans.net/ ,można też z lini komend), oczywiście żeby nie bawić się partycjami najlepiej cały rozruch przenieść sobie do głównego magazynu rozruchowego.
Tak przy okazji, masz oddzielną partycję dla plików botujących czy są one umieszczone na partycji windowsa?

ps.
listingi wstawiaj bezpośrednio do posta w tagach "spoiler" np.:

tu mamy coś

pzdr

[iksigrek]

Ok, tylko nie wiem czy to ma sens. O ile dobrze rozumiem OK® to tylko wyzwalacz, więc teoretycznie jeśli wybiorę dowolnym softem na rozruchową partycję z plikami bootującymi, to powinno to ruszyć, a OK sprawia, że cały proces jest wygodniejszy, czy tak ? Tylko, że ja nie mogę po aktywowaniu partycji recovery się odpalić w ogóle, bo wychodzi błąd. Nie zależy mi na tym, by robić to tym przyciskiem, ale by w ogóle zadziałało ; ). Chyba, że źle strzelam, bo po prostu nie wiem jak to działa i OK zdefiniowany wskazanym przez Ciebie softem wszystko naprawi ?

 

Pierwsza partycja z toolsami lenovo ma swoje pliki bootujące (jest tam ukryty katalog Boot i plik bootmgr, a w pliku sdrive jest info "Lenovo Service Partition Ver 1.0.0.2009). Na tej z systemem też mam Boot'a i bootmgr. Chodzi o jakieś jeszcze pliki by partycja posiadała komplet plików bootujących ?

 

Wychodzi więc na to, że mam dwie partycje mogące niezależnie bootować, ale po ustawieniu aktywnej na tą "Lenovo service" wywala błąd opisany powyżej.

 

W sumie to na partycji "Lenovo_recovery" w katalogu "FactoryRecovery" są jeszcze dwa pliki, może to coś pomoże:

bcdinfo.txt (Po co to tu ? Skoro Recovery bootuje z tej drugiej partycji z toolsami)

 

 

Windows Boot Manager

--------------------

identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}

device                  partition=S:

description             Windows Boot Manager

locale                  en-us

inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}

extendedinput           Yes

default                 {6e843dca-c5af-11de-a727-00226817af66}

resumeobject            {6e843dc9-c5af-11de-a727-00226817af66}

displayorder            {6e843dca-c5af-11de-a727-00226817af66}

                        {5294fec2-9af8-11dd-9fa0-f9e85e02c230}

toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}

timeout                 0

customactions           0x10000ba000001

                        0x54000001

custom:54000001         {572bcd55-ffa7-11d9-aae0-0007e994107d}

 

Windows Boot Loader

-------------------

identifier              {5294fec2-9af8-11dd-9fa0-f9e85e02c230}

device                  ramdisk=[C:]\SWWORK\AUDITPE.WIM,{ae5534e0-a924-466c-b836-758539a3ee3a}

path                    \windows\system32\boot\winload.exe

description             AuditPE

osdevice                ramdisk=[C:]\SWWORK\AUDITPE.WIM,{ae5534e0-a924-466c-b836-758539a3ee3a}

systemroot              \windows

detecthal               Yes

winpe                   Yes

 

Windows Boot Loader

-------------------

identifier              {572bcd55-ffa7-11d9-aae0-0007e994107d}

device                  ramdisk=[boot]\tvtos\winpe.wim,{ae5534e0-a924-466c-b836-758539a3ee3a}

path                    \windows\system32\boot\winload.exe

description             WinPE

osdevice                ramdisk=[boot]\tvtos\winpe.wim,{ae5534e0-a924-466c-b836-758539a3ee3a}

systemroot              \windows

nx                      OptIn

detecthal               Yes

winpe                   Yes

 

Windows Boot Loader

-------------------

identifier              {6e843dca-c5af-11de-a727-00226817af66}

device                  partition=C:

path                    \Windows\system32\winload.exe

description             Windows 7

locale                  en-us

inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}

osdevice                partition=C:

systemroot              \Windows

resumeobject            {6e843dc9-c5af-11de-a727-00226817af66}

nx                      OptIn

 

Resume from Hibernate

---------------------

identifier              {6e843dc9-c5af-11de-a727-00226817af66}

device                  partition=C:

path                    \Windows\system32\winresume.exe

description             Windows Resume Application

locale                  en-us

inherit                 {1afa9c49-16ab-4a5c-901b-212802da9460}

filedevice              partition=C:

filepath                \hiberfil.sys

pae                     Yes

debugoptionenabled      No

 

Windows Memory Tester

---------------------

identifier              {b2721d73-1db4-4c62-bf78-c548a880142d}

device                  partition=S:

path                    \boot\memtest.exe

description             Windows Memory Diagnostic

locale                  en-us

inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}

badmemoryaccess         Yes

 

EMS Settings

------------

identifier              {0ce4991b-e6b3-4b16-b23c-5e0d9250e5d9}

bootems                 Yes

 

Debugger Settings

-----------------

identifier              {4636856e-540f-4170-a130-a84776f4c654}

debugtype               Serial

debugport               1

baudrate                115200

 

RAM Defects

-----------

identifier              {5189b25c-5558-4bf2-bca4-289b11bd29e2}

 

Global Settings

---------------

identifier              {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}

inherit                 {4636856e-540f-4170-a130-a84776f4c654}

                        {0ce4991b-e6b3-4b16-b23c-5e0d9250e5d9}

                        {5189b25c-5558-4bf2-bca4-289b11bd29e2}

 

Boot Loader Settings

--------------------

identifier              {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}

inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}

                        {7ff607e0-4395-11db-b0de-0800200c9a66}

 

Hypervisor Settings

-------------------

identifier              {7ff607e0-4395-11db-b0de-0800200c9a66}

hypervisordebugtype     Serial

hypervisordebugport     1

hypervisorbaudrate      115200

 

Resume Loader Settings

----------------------

identifier              {1afa9c49-16ab-4a5c-901b-212802da9460}

inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}

 

Setup Ramdisk Options

---------------------

identifier              {ae5534e0-a924-466c-b836-758539a3ee3a}

description             Ramdisk options

ramdisksdidevice        boot

ramdisksdipath          \boot\boot.sdi

 

 

 

 

 

RECOVERY.INI

 

 

[partition1]

size=1199

type=07

label=SYSTEM_DRV

volume=S

active=1

recfromsp=0

imagename=Sdrivebackup.wim

install=iuimagex.exe /apply /verify Q:\factoryrecovery\Sdrivebackup.wim 1 S:\

installsplit=iuimagex.exe /apply /verify Q:\factoryrecovery\Sdrivebackup.swm 1 S:\ /ref Q:\factoryrecovery\Sdrivebackup*.swm

[partition2]

size=

type=07

label=Windows7_OS

volume=C

active=0

recfromsp=0

imagename=Cdrivebackup.wim

install=iuimagex.exe /apply /verify Q:\factoryrecovery\Cdrivebackup.wim 1 C:\

installsplit=iuimagex.exe /apply /verify Q:\factoryrecovery\Cdrivebackup.swm 1 C:\ /ref Q:\factoryrecovery\Cdrivebackup*.swm

[partition3]

size=9999

type=07

label=Lenovo_Reco

volume=Q

active=0

recfromsp=0

imagename=Qdrivebackup.wim

install=iuimagex.exe /apply /verify Q:\factoryrecovery\Qdrivebackup.wim 1 Q:\

installsplit=iuimagex.exe /apply /verify Q:\factoryrecovery\Qdrivebackup.swm 1 Q:\ /ref Q:\factoryrecovery\Qdrivebackup*.swm

 

 

 

 

Nie wiem czy widziałeś, dodałem pełną listę plików z obu partycji recovery tutaj http://www.sendspace.pl/file/8944a1be365a5fc7c95ca33/recoverypartlist Sporo tego, wszystkie katalogi z podkatalogami, nie wiem czy wstawiać w spoiler, bo ma to 50kb spakowanego tekstu.

 

Próbowałem też ustawić wszystko tak jak ma to miejsce w Recovery.ini, ale to nic nie dało. Mam odnośnie tego pytanie: Czy jakiekolwiek znaczenie ma czy dysk z recovery będzie miał literę Q lub S nadaną przez disk managera windowsowego, skoro wszystko odpala się przed windowsem ?

 

Co może być problemem, skoro partycje odzysku teoretycznie są nie naruszone, mają niby bootowalne pliki na miejscu, ale po ustawieniu na aktywną tej bootującej wywala błąd. W ogóle to mam chyba pecha do tego, bo ostatnio trafiły mi się dwa kompy inne (jeszcze jeden lenovo i hp compaq) i tam też nie startuje. Ten sam problem - partycja jest, pliki bootowania są, okr nie działa, tak jak i aktywowanie "ręczne" partycji recovery z plikami bootującymi. W sumie dziwne jak te partycje mogły na tych komputerach nagle przestać działać. To zbieg okoliczności, jakiś złowrogi "timer" ustawiany przez serwisy po to, by komputery u nich lądowały po gwarancji czy może jakiś soft typu antywirus albo cleaner coś z nich usuwa próbując być pożytecznym (choć w sumie raczej nie były widoczne jako dyski, więc ciężko by mu było to zrobić...) ?

[maggreg]

Przepisanie konfigu do głównego kontenera rozruchu jest wygodne właśnie dlatego, że uwalnia nas od manipulowania rozruchem partycji, oprócz zaznaczenia takiej jako aktywnej trzeba się jeszcze upewnić, że posiada ona odpowiedni bootsector a w samym kontenerze jest zachowana kolejność urządzeń do których następuje odwołanie. Litery o których piszesz to tylko ilustracja pokazana na podstawie przypisań w systemie z którego odczytujesz bcd faktycznie stosowane są ścieżki bezwzględne np: "partition=\Device\HarddiskVolume9", można się domyślić, że w typowej konfiguracji to pierwsza partycja na trzecim dysku, można też określić jeszcze dokładniej odwołanie: "partition=\device\harddisk0\partition1" wtedy mamy pewność że odwołujemy się do konkretnego dysku i partycji na nim.

W praktyce problem może stanowić odwołanie do urządzenia boot które w stosunku do systemu z którego magazyn odczytujemy może się zmienić.

Jeżeli odwołanie nie znajdzie ścieżki wtedy widzimy coś na kształt: "device unknown".

W przypadku odpalanie winpe z pliku wim wązna jest też obecność w skonfigurowanej ścieżce ramdysku "boot.sdi".

Teraz kwestia skąd błędy, jeżeli ustawisz botowanie z tej partycji recovery to domyślnie odpala się wpis "{default}" który - jak wynika z listingu" próbuje uruchomić normalnie system tyle że z bliżej nieokreślonego urządzenia.

Natomiast interesujący nas system wim odpali się jeżeli bootstrap złapie sygnał naciśnięcia klawisza (kombinacji klawiszy) ukrywających się pod kodem "ba00", niestety taki kod w ogólnych tabelach klawiszy nie istnieje więc można przypuszczać, że dotyczy on klawisza specyficznego dla danego modelu laptopa. Czy klawisz generuje odpowiedni kod to inna sprawa, domyślnie powinien on robić więcej niż tylko to więc może nie działać.

Co można zrobić, przynajmniej kilka rzeczy, po pierwsze spróbować przypisać jeden z ogólnych kodów klawiszy F zastępując wpis domyślny, np:

 

bcdedit /set {bootmgr} customactions 0x0001000043000001 0x0000000054000001

 

Po drugie można dopisać ten element do menu rozruchu, ustawić timeout i wybrać wpis przy rozruchu ew. ustawić go jako domyślny:

 

bcdedit /toolsdisplayorder {572bcd55-ffa7-11d9-aae0-0007e994107d} /addlast

bcdedit /set {bootmgr}  timeout 30

 

lub

 

bcdedit /toolsdisplayorder {572bcd55-ffa7-11d9-aae0-0007e994107d} /addfirst

bcdedit /set {bootmgr}  default  {572bcd55-ffa7-11d9-aae0-0007e994107d}

 

Można też utworzyć od podstaw cały kontener z interesującym nas wpisem lub (co wcześniej sugerowałem) dodać ten wpis do głównego kontenera rozruchu (to oczywiście ma sens jeżeli partycja z głównym kontenerem nie jest nadpisywana przy recovery - praktyka tu jest różna).

 

A dlaczego recovery nie działają, bo z sobie tylko znanych powodów producenci sprzętu prześcigają się aby jak najbardziej zagmatwać ten proces byle tylko użytkownicy nie zajżeli jaki mechanizm się za nim kryje, tymczasem można to zrealizować w bardzo prosty sposób bez odwoływania się do jakichkolwiek zewnętrznych rozwiązań, wszystkie potrzebne narzędzia dał MS.

Zresztą wpisy w recovery.ini sugerują, że w użyciu jest właśnie microsoftowy system pakowania zawartości partycji tylko zamiast użyć czystego imagex mamy jakieś niepotrzebne śmieci od kasperskiego.

Inną sprawą jest też sama przydatność recovery, z założenia jest to zestaw "na dzień utworzenia" który po instalacji trzeba i tak zaktualizować (poprawki, sterowniki itp) więc zamiast recovery (które najczęściej dodaje jeszcze masę śmieci, często w wersjach próbnych) trzymać na taje partycji czystą instalkę systemu (obraz czystego systemu) plus aktualizowane na bieżąco repozytorium sterowników a najlepiej po prostu dbać o system tak żeby reco nie było do niczego potrzebne .

 

pzdr