Po nieczystym zamknięciu urządzenia z kartą SD, zabrałem kartę SD do fsck
głównego systemu plików. Doprowadziło to do zmian w następujących kwestiach:
e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2
Tutaj odpowiedziałem „nie” za każdym razem, ale nie ma sekwencji tak / nie, która nie od razu prowadzi do tego samego rezultatu.
System plików można zamontować i przy codziennej kontroli wydaje się być w porządku; działa również dobrze w urządzeniu, i to jest główny system plików (w rzeczywistości okazało się, że nie jest całkiem w porządku, patrz komentarze; tldr niektórych nieodwracalnie uszkodzonych katalogów).
Byłbym dd
partycją (8 GB) do pliku i spróbowałem na tym fsck. Co ciekawe:
e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)
Kolejne fsck
przekazane czyste, obraz można zamontować, a fsck -f
następnie mija.
Ale system plików na karcie, z którego utworzono nieprzetworzony obraz kopii bloku, wciąż ma ten sam problem - z tym wyjątkiem, że ten, systemd-fsck
który ma miejsce podczas rozruchu, rejestruje system plików jako „czysty”. Później jednak prawidłowe zamknięcie, wyjęcie karty i ponowienie próby fsck
z innego pudełka powoduje ten sam błąd.
Ilekroć oryginał jest zamontowany na innym komputerze, syslog zauważa:
kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete
Ponieważ mam kopię zapasową, jestem otwarty na cokolwiek tutaj. Mógłbym po prostu zapomnieć o tym i ponownie wypalić partycję z pozornie naprawionego obrazu, ale nie wydaje się to bardzo zadowalającym rozwiązaniem, ponieważ oznacza założenie, że fsck w sposób tajemniczy nie rozwiązał drobnego problemu.
Podejrzewam, że zmieni się to w pytanie „prośba o oficjalną dokumentację” dotyczące takich rzeczy, jak potrzebne hasło recovery_flag (lub po prostu zwykłe pytanie „co to znaczy?”), Więc wszelkie sugestie w tym zakresie są mile widziane.
apt upgrade
). Następnie loguje się do normalnego rozruchu - a systemd-fsck mówi „wyczyść” (zmodyfikuję to), ale próba fsck poza tym kontekstem nadal kończy się niepowodzeniem.Odpowiedzi:
Właśnie natrafiłem na ten sam problem. Po debugowaniu problemu z
e2fsck
opiekunem zdaliśmy sobie sprawę, że karta SD została uszkodzona. Przyjmował zapisy bezbłędnie, ale tak naprawdę nie zapisywał danych na kartę. Karta SD była efektywnie tylko do odczytu.Wygląda na to, że karta przeszła w tryb awaryjny, w którym dane nadal można było odczytać, ale nic nie napisano.
Na
e2fsck
wiadomośćunable to set superblock flags
oznacza to próbowałem pisać do superbloku zaznaczyć dziennik jako przetworzony, co wydarzyło się bez błędu, ale kiedy poszedłem do zapoznania się z powrotem superblok nadal wskazywały, że czasopismo musiała zostać powtórzona. Innymi słowy, zmiany zapisane w superbloku nie zostały zapisane na nośniku pamięci.Karta, której używam, ma ten problem, to microSD Samsung Evo 16 GB, o której wspominam na wszelki wypadek z tymi kartami.
Byłem w stanie to przetestować,
dd
zapisując 4096 bajtów z/dev/zero
karty na bloku w bloku 0, a następnie odczytałem z karty i zamiast otrzymywać wszystkie zera tak jak powinienem, nadal otrzymałem oryginalny niezmieniony superblok ext4.Jestem teraz w trakcie przenoszenia danych na nową kartę, a następnie sprawdzam, czy mogę uzyskać zamiennik od Samsunga, który wydaje się oferować 10-letnią gwarancję na karty SD.
AKTUALIZACJA: Samsung wymienił kartę 16 GB na 32 GB z tej samej serii Evo, więc zgadnij, że nie mogę narzekać zbytnio!
źródło
Wiem, że to stary wątek, ale pomyślałem, że dam trochę wglądu.
Wygląda na to, że karty SD umierają naturalną śmiercią. Liczba cykli odczytu / zapisu, które mogą wytrzymać karty SD, jest znacznie niższa niż w przypadku większości innych nośników uważanych za „odczyt / zapis”. Po wyczerpaniu karta przejdzie w tryb tylko do odczytu, ale nie poinformuje Cię o tym. Wiele rzeczy myśli, że piszą na kartę dzięki buforowaniu systemu operacyjnego itp., Ale nic nigdy się nie trzyma.
Świetnym sposobem na zabicie karty SD jest zamontowanie jej jako partycji wymiany lub czegoś bardzo intensywnego do odczytu / zapisu. Byłbyś zaskoczony, jak szybko możesz zabić kartę w ten sposób. Przekonałem się, że uruchomienie knoppiksa z karty SD lub napędu USB trwa tylko miesiąc lub dwa, w zależności od jakości karty i intensywności użycia knoppiksa. (Od tego czasu przełączyłem się na uruchamianie knoppiksa z dysku USB SSD, który trwał już kilka lat).
źródło