Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Witam,
Posiadam zaszyfrowaną macierz RAID 1 pod /home. Ustawiłem sobie, aby montowała się automatycznie po zalogowaniu (opierając się o http://nanonanonano.net/linux/debian/enchome). Wszystko przez kilka miesięcy działało perfekcyjnie. Aż do dziś... Po zalogowaniu ujrzałem "czysty" profil użytkownika. Od razu wiedziałem, że nie zamontował się zaszyfrowany dysk pod /home. Niestety ręczne montowanie się nie powiodło:
root@s4per-debian:/home/s4per# cryptsetup luksOpen /dev/mapper/isw_echheajchc_Mirror crypt Numer klucza LUKS 4 jest nieprawidłowy.
Z tego co wyczytałem może to oznaczać problem z nagłówkiem. Niestety i tak nie wiem jak to ruszyć dalej.
Serdecznie proszę o pomoc bardziej doświadczonych kolegów.
Wersja Debiana: Sid AMD64
Ostatnio edytowany przez s4per (2014-11-26 18:17:20)
Offline
root@s4per-debian:/home/s4per# cryptsetup luksDump /dev/mapper/isw_echheajchc_Mirror Numer klucza LUKS 4 jest nieprawidłowy.
Offline
Offline
No niestety nie mam backupu nagłówków... Ale na szczęście mam backup najważniejszych danych ;)
Ale nie zmienia to faktu, że chciałbym odzyskać wszystkie dane.
Offline
Teraz to już nic nie zrobisz. xD
Ja mam "kopię" swojego 1,5TB dysku (11 partycji) upchniętą w 50MiB zaszyfrowanym kontenerze ulokowanym na kilku serwerach na necie i w sumie to nie wyobrażam sobie sytuacji, w której mógłbym stracić dane zawarte na tym nośniku, oczywiście pomijam fizyczne uszkodzenie dysku. xD
Offline
Zasięgnąłem języka u developerów i rozwiązanie okazało się proste.
cryptsetup repair <device>
Oczywiście koniecznie należy poprzedzić próbę naprawy backupem nagłówków.
Offline
Add repair command and crypt_repair() for known LUKS metadata problems repair.
Some well-known LUKS metadata corruptions are easy to repair,
this command should provide a way to fix these problems.
Always create binary backup of header device before running repair,
(only 4kB - visible header) for example by using dd:
dd if=/dev/<device> of=repair_bck.img bs=1k count=4
Then you can try to run repair: cryptsetup repair <device>
Note, not all problems are possible to repair and if keyslot or some header
parameters are overwritten, device is lost permanently.
Także nie wszystko idzie tym naprawić i lepiej uważać. xD
Offline
Strony: 1