Dlaczego mój dysk flash stał się "tylko do odczytu" i (jak) mogę to naprawić?
Mam całkiem nowy dysk flash (sprzed tygodnia), który został oznaczony jako tylko do odczytu przez Windows, Kubuntu i bootowalnego partycjonera. Dlaczego tak się stało? Czy da się to naprawić? Jeśli tak, jak mogę to naprawić?
Problem
Po pierwsze, ten dysk jest nowy. Na pewno nie był używany na tyle, aby umrzeć z powodu normalnego zużycia, choć nie wykluczałbym wadliwych komponentów.
Sam dysk został w jakiś sposób zablokowany w stanie tylko do odczytu. Zarządzanie dyskami w systemie Windows:
Generic Flash Disk USB Device
Disk ID: 33FA33FA
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : Yes
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
Diskpart:
Warning: Only 7762 of 7812 MByte tested.
The media is likely to be defective.
7.5 GByte OK (15896472 sectors)
52 KByte DATA LOST (104 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
52 KByte corrupted (104 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000186003000
Expected: 0x0000000186003000
Found: 0x00200800c40c3061
H2testw version 1.3
Writing speed: 3.95 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4
To co mnie naprawdę zmyliło to Current Read-only State : Yes i Read-only : No.
Próbowane rozwiązania
Do tej pory próbowałem:
Formatowanie go w Windows (w Zarządzaniu dyskami opcje formatowania są wyszarzone po kliknięciu prawym przyciskiem myszy).
DiskPart Clean (
CLEAN - Clear the configuration information, or all information, off the disk.):Formatowanie w wierszu poleceń Windows
Windows chkdsk: szczegóły poniżej
Kubuntu fsck (przez VirtualBox USB passthrough): szczegóły poniżej
Acronis True Image do formatowania, do konwersji na GPT, do zniszczenia i odbudowania MBR, w zasadzie cokolwiek: failed (could not write to MBR)
Details (and a nice story)
Background
To był całkiem nowy, generyczny, 8GB pendrive, z którym chciałem stworzyć multiboot flash drive. Był sformatowany jako FAT32, choć dziwnie trochę większy niż większość 8-gigabajtowych pendrive'ów, z którymi się zetknąłem. Około 127MB było wymienione przez Windows jako “używane”. Nigdy nie dowiedziałem się dlaczego. Końcowa przestrzeń użytkowa była mniej więcej taka, jakiej normalnie oczekuję od dysku 8GB (około 7,4 GIBIbajtów).
Wrzuciłem na niego kilka dystrybucji Linuksa, wraz z kopią Hirena. Wszystkie uruchamiały się idealnie. Zostały zainstalowane za pomocą YUMI .
Kiedy próbowałem postawić DVD z Knoppixem, YUMI dodało dziwną opcję video do komendy bootowania, która spowodowała, że Knoppix startował z czarnym ekranem na X-ach. ttys 1 do 6 wciąż działały jako interfejsy tekstowe.
Kilka dni później, poświęciłem trochę czasu na usunięcie tej dziwnej opcji video, dzięki czemu komenda bootowania jest zgodna z tą, która jest dostarczana z Knoppixem. Przy próbie bootowania Knoppix zgłosił jakąś formę uszkodzenia LZMA.
Prowadząc do obecnego problemu
Myślałem, że pliki Knoppixa mogły być jakoś uszkodzone, więc spróbowałem go przeładować. Dysk był prawie pełny (45MB wolnego miejsca), więc usunąłem generyczne ISO, które również się nie uruchamiało. Poszło dobrze. Następnie przeszedłem przez YUMI, aby “odinstalować” Knoppixa, tj. usunąć pliki i usunąć z menu. Pliki zostały usunięte jako pierwsze, następnie menu zostało wyczyszczone pomyślnie. Jednakże wolna przestrzeń utknęła na około 700MB, tak samo jak przed usunięciem Knoppixa. W starym folderze Knoppixa znajdował się 0-bajtowy plik o nazwie KNOPPIX, którego nie można było usunąć.
Próbowałem ponownie włożyć dysk, aby usunąć ten plik - bez bezpiecznego usuwania, jeśli to coś zmieniło (hej, pierwszy raz na wszystko). Uruchomienie standardowego skanowania Windows chkdsk bez /r lub /f zgłosiło znalezione błędy. Uruchomienie z /r spowodowało, że po prostu utknął.
Postanowiłem spróbować z fsck, więc załadowałem maszynę wirtualną Kubuntu i podłączyłem do niej dysk za pomocą USB 2.0 passthrough VirtualBoxa. Zanotowałem umount (/dev/sda1) i wykonałem fsck. There are differences between boot sector and its backup. wybrałem No action. Poinformował mnie, że FAT się różnią i poprosił mnie o wybranie pierwszego lub drugiego FAT. Niezależnie od tego, który wybrałem, otrzymałem informację o Free cluster summary wrong. Jeśli wybrałem Correct, dało to listę nieprawidłowych nazw plików. Aby spróbować naprawić coś, przynajmniej, uruchomiłem go z opcją -p. W połowie naprawiania plików maszyna zamarzła - zakończyłem jej proces jakieś dziesięć minut później.
Przyczyna?
Następną próbą było użycie YUMI, ponownie, do odbudowania całego dysku. Użyłem wbudowanej w YUMI opcji reformat (do FAT32) i zainstalowałem Kubuntu ISO (700MB). Formatowanie przebiegło pomyślnie, jednak proces rozpakowywania i kopiowania Kubuntu (do którego YUMI używa binarki 7zip) zamarł w około 60%. Po odczekaniu około piętnastu minut (dłużej niż ostatnio zajęło 3,5GB ISO Knoppixa), wyciągnąłem dysk. Dysk w tym momencie był już sformatowany, SYSLINUX już zainstalowany, czekał tylko na rozpakowanie ISO i modyfikację boot menu.
Podłączając go z powrotem, dysk pojawił się normalnie - jednak wszelkie operacje zapisu kończyły się niepowodzeniem. Zarządzanie dyskami zgłosiło go jako tylko do odczytu. Po ponownym podłączeniu, pojawiłby się normalnie, ale operacja zapisu spowodowałaby, że znowu byłby tylko do odczytu. Po kilku próbach, zaczęło się pojawiać jako read only przy wstawianiu.
Próby naprawienia
To jest moment, w którym przeprowadziłem próby wymienione powyżej, aby spróbować sformatować go ponownie w przypadku wadliwego formatu. Jednak niemożność zrobienia tego nawet na dysku startowym wskazywała, że coś poważniejszego jest nie tak. chkdsk teraz zgłasza, że nic nie jest nie tak, a fsck nadal zgłasza niespójności MBR, ale teraz zawsze wybiera pierwszy FAT automatycznie, po tym jak powiedział mi, że FAT-y się różnią. To wciąż robi to samo Free cluster summary wrong po tym. Nie mogę już uruchomić z -p, ponieważ jest teraz oznaczony jako tylko do odczytu. Udało się również uszkodziłem dysk mojej maszyny wirtualnej jakoś przy pierwszej próbie (tak, jestem pewien, że wybrałem sda, który jest zmapowany na dysk o pojemności 7,4GB - trzykrotnie sprawdzałem). Dzięki Bogu za snapshoty?
Kończą mi się pomysły. Dla mojego niedoświadczonego umysłu wygląda to tak, jakby coś w firmware dysku ustawiło go na “stałe” tylko do odczytu - czy jest jakiś sposób, żeby to zresetować? Nie zależy mi szczególnie na zachowaniu danych, biorąc pod uwagę, że formatowałem go już dwa razy.
Lepsze są też poprawki, które utrzymują mnie w Windowsie; zmniejsza to ryzyko, że przypadkowo zniszczę mój główny dysk twardy.
Aktualizacja 1:
Rozebrałem dysk z ciekawości.
Jak widać, nie ma żadnych oczywistych przełączników zabezpieczających przed zapisem. Po drugiej stronie znajduje się układ scalony, marki ALCOR, oznaczony jako AU6989HL, jeśli to ma jakieś znaczenie. Jeśli nie ma sposobu, aby to naprawić, prawdopodobnie wyciągnę (przyklejoną) kartę i włożę ją do czytnika kart, aby sprawdzić, czy to karta, czy kontroler padł.
Aktualizacja 2:
Wyciągnąłem kartę, Windows wykrywa teraz napęd jako czytnik kart. Styki na karcie nie wydają się być używane, a na samej karcie jest kilka rzędów otworów. Włożenie jej do czytnika kart wykrywa tylko około 30MB, RAW. Prawdopodobnie albo oryginalny napęd błędnie zgłasza kartę jako wadliwą (tak jakby ochrona przed zapisem prawdziwej karty SD była włączona), albo gdzieś jest uszkodzony styk.
Jeśli nic więcej, mam teraz zapasową kartę Micro SD 8GB… jak tylko wymyślę jak sformatować ją jako 8GB. Co nie wydaje się być możliwe (Windows, Partedmagic, dd, DBAN… nieee, wciąż 30MB). Ah no cóż.
Update 3
Miałem jeszcze kilka takich przypadków. Drugi dzisiaj uległ podobnej awarii (tylko do odczytu). Z pozostałych, dwa zostały wykryte jako puste czytniki kart/nieformatowane dyski, w zależności od potrząsania (uszkodzony styk?). Jeden został wykryty jako zapełniony w 1/3 i miał dziwną nazwę woluminu. Wyniki
H2testw (na ostatnim w pełni sprawnym, jaki posiadam!):
Choć jest to nieco niepokojące, najwyraźniej dyski faktycznie mają pojemność bliską 8GB, co zostało zweryfikowane przez narzędzie często z powodzeniem wykorzystywane do wykrywania fałszywych pendrive'ów. Użycie karty Micro SD zamiast oznaczonego modułu pamięci flash sprawia, że reflashowanie dysku jest prawie niemożliwe, ponieważ narzędzia do flashowania dysków firmy Alcor oczekują modelu pamięci jako parametru. Chyba po prostu wyrzucę całość.