2012-11-25

Naprawa wehikułu czasu

Po raz kolejny mojemu backupu trafiła się przypadłość pod tytułem "To improve reliability, Time Machine must create a new backup for you".


Przy pierwszym razie rzeczywiście pozwoliłem na utworzenie nowej kopii (tracąc wszystkie poprzednie). Przy drugim pomyślałem że w końcu co, kurczę blade, nie po to się robi backupy aby je potem tracić, odłączyłem dysk od routera, podpiąłem do komputera i - posiłkując się kilkom tutorialami z sieci - reanimowałem go. Przy trzecim razie uznałem, że trzeba wiedzę zebrać w jednym miejscu bo najwyraźniej będzie się od czasu do czasu przydawać. Uruchamiamy Terminal i:

1) Po podłączeniu dysku do komputera zostanie on automatycznie zamontowany. U mnie nazywa się Time Machine, więc jest dostępny jako /Volumes/Time\ Machine i zawiera tylko jeden plik: nazwa.sparsebundle.

2) Profilaktycznie ustawiamy uprawnienia - system po stwierdzeniu, że kopia jest uszkodzona może ustawić immutable flag (nie wiem od czego to zależy - w tutorialach o tym nie było, ale u mnie tak robi).
Uwaga: tę i wszystkie dalsze komendy musimy wykonywać z uprawnieniami administratora, stąd przed każdą sudo.

sudo chflags -R nouchg /Volumes/Time\ Machine/nazwa.sparsebundle

3) Dołączamy (ale nie montujemy) wirtualny dysk z kopią zapasową:

sudo hdiutil attach -nomount -noverify -noautofsck /Volumes/Time\ Machine/nazwa.sparsebundle

System wypisze znajdujące się na nim partycje (mogą mieć inne numery):

/dev/disk3           Apple_partition_scheme        
/dev/disk3s1         Apple_partition_map            
/dev/disk3s2         Apple_HFSX 

4) Interesuje nas ostatnia z partycji, to na niej jest backup i ona jest weryfikowana. Aby ją naprawić trzeba wykonać komendę:

sudo fsck_hfs -fyrd /dev/disk3s2

Znaczenie poszczególnych opcji:

-f (force) wymusza sprawdzenie i naprawę, nawet gdyby system uważał inaczej

-y próbuje naprawiać wszelkie znalezione nieprawidłowości

-r (rebuild) przebudowuje b-drzewo katalogów (cokolwiek to znaczy - w tutorialach sugerują, aby to zrobić)

-d (debug) będzie wypisywać sporo informacji w terminalu ale dzięki temu będziemy wiedzieli, że coś się dzieje (proces sprawdzania może trwać nawet kilka godzin)

5) Całkiem możliwe, że fsck_hfs odmówi współpracy i napisze:

Unable to open block device /dev/disk3s2:
Resource busyjournal_replay(/dev/disk3s2) returned 16
** /dev/rdisk3s2 (NO WRITE)

co znaczy, że system po podłączeniu dysku zaczął automatyczne sprawdzanie i trzeba poczekać aż skończy. Aby stwierdzić kiedy to nastąpi należy zajrzeć do logu:

tail -f /var/log/fsck_hfs.log

będzie tam:

** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.

i po jakimś czasie pojawi się:

/dev/rdisk3s2: ** The volume Time Machine Backups could not be verified completely.

wtedy możemy wrócić do punktu 4).

6) Drugi z możliwych problemów to:

Unable to open block device /dev/disk3s2:
Permission deniedjournal_replay(/dev/disk3s2) returned 13
** /dev/rdisk3s2 (NO WRITE)

- tutaj pomaga restart komputera

7) Kiedy fsck_hfs zacznie pracę wypisze (m. in.):

** Checking Journaled HFS Plus volume.
...
** Rebuilding catalog B-tree.

i po dłuższym czasie:


** Rechecking volume.

Jeżeli po kolejnym sprawdzaniu zobaczymy niezbyt zachęcający komunikat:


** The volume Time Machine Backups could not be repaired.

nie należy się tym zrażać tylko uruchomić fsck_hfs po raz kolejny. W moim przypadku dopiero za drugim razem zobaczyłem oczekiwane:

** The volume Time Machine Backups was repaired successfully.
CheckHFS returned 0, fsmodified = 1

8) Pomimo, że partycja z kopią zapasową jest już naprawiona, to system nie rejestruje tej informacji - musimy zrobić to ręcznie edytując plik com.apple.TimeMachine.MachineID.plist:

sudo nano /Volumes/Time\ Machine/nazwa.sparsebundle/com.apple.TimeMachine.MachineID.plist 

dla klucza:

VerificationState

zmieniamy wartość 2 na 0.

Gotowe!

2012-02-18

(Uszkodzony) FireWire kontratakuje

Po przejściach z instalacją Liona opisanych tutaj dwa duże update'y (10.7.1 i 10.7.2) nie sprawiły mojemu MacBookowi żadnych problemów. Jednak po zainstalowaniu wersji 10.7.3 system przestał się uruchamiać, prezentując znane i nieszczególnie lubiane objawy niekończącego się oczekiwania na inicjalizację FireWire. Możliwe, że sam sobie strzeliłem w kolano, ponieważ po przeczytaniu o problemach z tą aktualizacją nie instalowałem jej przyrostowo (przez System Update), ale ściągnąłem pełną wersję (Combo). Problemów opisywanych na forach nie doświadczyłem, ale najwyraźniej system został przywrócony do stanu fabrycznego. Na szczęście tym razem sprawę udało się załatwić w kilka minut: wystarczyło zabootować system w single user mode (naciskając command-s podczas uruchamiania komputera), zamontować dysk z możliwością zapisu (/sbin/fsck -y, /sbin/mount -wu /) a następnie skasować moduł IOFireWireFamily (rm -rf /System/Library/Extensions/IOFireWireFamily.kext). Voilà! Do następnego razu.

[aktualizacja 2012.10.13]

Po zainstalowaniu wersji 10.7.4 jest ok, w 10.7.5 problem znowu się pojawia. Na szczęście powyższy sposób nadal jest skuteczny.
© The Useful Pot To Keep Things In
Maira Gall