Raspberry Pi, Raspbian i problemy z kartami microSD

Jakieś siedem tygodni temu pisałem, że padła mi karta microSD (Kingston) w Raspberry Pi. Wymieniłem na nową (Goodram). Zamontowana oszczędnie, tj. bez journala i z symlinkiem /var/lib/transmission-daemon/info kierującym na dysk twardy. Wczoraj robię aktualizację systemu, a tu nagle:

Preparing to replace libssl1.0.0:armhf 1.0.1e-2+rvt+deb7u7 (using .../libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb) ...
Unpacking replacement libssl1.0.0:armhf ... dpkg: error processing /var/cache/apt/archives/libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb (--unpack):
error creating directory `./usr/share/doc/libssl1.0.0': Input/output error
Segmentation fault Segmentation fault -bash: mbrtowc.c:92: __mbrtowc: Assertion `status == __GCONV_OK || status == __GCONV_EMPTY_INPUT || status == __GCONV_ILLEGAL_INPUT || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT' failed.

Piękne, prawda? Oczywiście kluczowy jest input/output error. Fsck, są błędy, naprawiony filesystem. Coś mnie tknęło i sprawdziłem badblocks (badblocks -sv). Tak jest, błędy w okolicy 90% karty (dead link). Sztuk prawie 30. Wygląda, że karta Goodram wytrzymała w komfortowych warunkach raptem 7 tygodni. Masakra.

Z tego wszystkiego zacząłem sprawdzać, co pisze na dysk (iotop -ao). Wyniki (sortowane po ilości zapisów, czas działania kilka godzin) są ciekawe:

3192 be/4 root 8.00 K 4.03 M 0.00 % 0.00 % rsyslogd -c5
2184 be/4 root 240.00 K 880.00 K 0.00 % 0.00 % nmbd -D
3341 be/4 ntp 248.00 K 188.00 K 0.00 % 0.00 % ntpd -p /var/run/ntpd.pid -g -u 102:104
5256 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u2:2]
2911 be/4 root 208.00 K 88.00 K 0.00 % 0.00 % -bash

Jak widać, głównie rsyslog. I raczej nie ma tego wiele.

I tu zaczyna się część najciekawsza. Pamiętacie uszkodzoną kartę Kingstona? Przygotowałem się do pozbycia się jej, poleciał shred. Stwierdziłem, że uruchomię badblocks na niej. I… niespodzianka. Teraz nie zgłasza błędów. Ani w teście odczytu (domyślny), ani w niedestrukcyjnym teście zapisu (badblocks -nvs). Naprawiło się?

Zaczynam podejrzewać jakiegoś buga z przejściówką microSD -> SD (ale są dwie różne, bo każda karta miała swoją), gniazdem w rpi (ale działało OK, poza tym i badblocks, i fsck robię w laptopie). Zagadka.

Ostatecznie zmniejszyłem rozmiar partycji ext4 na karcie Kingstona i działa do tej pory bez problemu. Czyli jakieś 3 tygodnie bezproblemowego działania, bo wpis zacząłem tworzyć 12 czerwca.

UPDATE: Zwariowałem. Goodram, który ewidentnie miał błędy, bo nie tylko badblocks je wykazywał, ale nawet shred puszczony przed wyrzuceniem powodował błędy IO i nie mógł dobrnąć do końca (a próbowałem nie raz), teraz działa. Nagrałem Raspbiana dla Banana Pi, test badblockiem i… czysto. WTF?

Kingdom Rush – Frontiers

Blisko dwa i pół roku temu zachwalałem Kingdom Rush. Po przyjeździe na urlop (pogoda różna, nie jest źle, ale bywało lepiej…) okazało się, że została wydana kolejna część. Gra nadal trzyma poziom, choć nie widzę wersji płatnej, a tylko darmową. I jakby trochę prostsza od części pierwszej jest.

Screenshot z Kingdom Rush Frontiers

Źródło: http://www.kingdomrushfrontiers.com/

Na poziomie trudności normal skończyłem bez problemu w trybie campaign. Wszędzie trzy gwiazdki, za wyjątkiem ostatniego etapu, gdzie dwie gwiazdki (póki co). Tryby dodatkowe (heroic challange, iron challange) również bez większych problemów na normal, za wyjątkiem etapu czwartego, którego nie udało mi się – póki co – zrobić na normal.

W każdym razie lekko licząc rozrywka na trzy wieczory zapewniona. A jeszcze nie koniec (choć przyznaję, że parcia na ukończenie na poziomie veteran nie mam.

Tutaj można zagrać online w Kingdom Rush Frontiers. W sumie offline też działa, tylko załadować się musi online.

Raspberry Pi jako NAS

Nie bardzo miałem co zrobić z moim Raspberry Pi, a przecież nie może się maszynka nudzić. Przy czym łącze do domu mam całkiem fajne i w praktyce po WiFi nie do wykorzystania[1], więc postanowiłem zrobić sobie seeder torrentów[2], serwer do backupu innych maszynek i ogólnie NAS dla domu. Niby coś jak Dockstar, ale nie głównie router, tylko z akcentem na NAS. W sumie może kiedyś dorzucę mini hosting dla własnych gadżetów. Na razie leży to sobie na dedyku, zresztą rpi demonem szybkości nie jest, więc z czymkolwiek ponad statyczne strony może być ciężko…

Nierozwiązaną miałem kwestię obudowy dla Raspberry Pi. Przy czym, gdybym zrobił to tradycyjnie, to byłby hub USB, kabelki do rpi, kabelki do dysku, kabel do zasilania, kabel do routera. Trochę plątanina, którą ciężko utrzymać w czystości, bo ani odkurzyć porządnie, ani przetrzeć szmatką. No i podatne na usterki, bo taki kabel na wierzchu jednak łatwo szturchnąć. Postanowiłem, że spróbuję upchać to wszystko w jedno pudło i zacząłem rozglądać się za jakimś dającym się wykorzystać gotowcem.

Pierwsze co mi wpadło w oko, to pudełka do żywności w Netto. Trzy sztuki (różnej wielkości) za 8 zł. Szybka przymiarka ujawniła, że średnie, na które liczyłem się nie nadaje, bo jest za małe. Za to największe pasuje. Na styk, zresztą, ale to dobrze – można zrezygnować z mocowania elementów w środku. Trochę bałem się, że plastik nie będzie odporny na temperaturę, ale niesłusznie. Według opisu pojemniki są przeznaczone do temperatur od -30 do +100 C i do użytku w mikrofali.

Układ elementów w pudełku następujący: na dole dysk w kieszeni, jako element najchłodniejszy i najcięższy, ma lekko miękkie etui z tworzywa, więc na nim bez obaw mogę położyć Raspberry Pi. Hub USB Unitek przymocowany do pokrywki przy pomocy opasek samozaciskowych (AKA żmijki). Po pierwsze jest metalowy, więc nie chcę go mieć w pobliżu rpi z uwagi na możliwe zwarcia, po drugie jego ażurowa obudowa sugeruje, że może się grzać. Pierwotnie rpi miało leżeć wzdłuż dysku, ale nie pasowało to do układu kabli. Zresztą jest na tyle małe, że w poprzek też praktycznie nie wystaje poza obrys dysku.

Miałem obawy o temperaturę w środku, bo wymiana powietrza jest mocno utrudniona. Nie było źle – S.M.A.R.T. dla dysku pokazywał góra 40 stopni, ale ostatecznie zdecydowałem się na dodanie otworów od spodu pudełka (w zamyśle wlot zimnego), zrobienie nóżek z podkładek filcowych (samoprzylepne do mebli) w celu umożliwienia dopływu powietrza do nich, oraz kilku otworów na samej górze z boku (w zamyśle wylot ciepłego powietrza; nie pokrywka, żeby kurz nie wpadał od góry do środka). Dzięki temu jakiś tam przepływ jest i odrobinę chłodniej.

Uroki notek po czasie są takie, że mogę napisać, jak to działało i czemu przestało. Działało bardzo dobrze i stabilnie. Jedyne restarty to braki prądu (rzadko się zdarza, ale się zdarza) lub wymiana kernela. Uptime po kilkadziesiąt dni. Wydajnościowo szału nie ma. Sam NTFS via ntfs-3g potrafił wskoczyć w top na pierwsze miejsce z kilkadziesiąt procent (40-60) zużycia CPU. Oczywiście NTFS jest tam tymczasowy – po prostu chwyciłem do testu dysk, który robił za przenośny. No i całość jak najbardziej wyrabiała się z serwowaniem plików po sambie po WiF. Tyle, że cokolwiek więcej w tym czasie na rpi było problematyczne. Dysk po USB jak najbardziej daje radę, ale ten element miałem przetestowany już wcześniej.

Dzięki temu, że miałem notkę o testowym uruchomieniu Raspberry Pi, wiem dość dokładnie, ile działało. Problemy (niemożność zalogowania się po SSH) zaczęły się na początku kwietnia, czyli podziałało jakieś 4 m-ce. Niestety, trafnie przewidziałem powód: pad karty micro SD (ja wiedziałem, że tak będzie… pamięci flash nie nadają się do zapisu ja wiedziałem, że tak będzie…). Początkowo uważałem, że to zwykłe zawieszenie, ale po restarcie po paru godzinach sytuacja się powtórzyła. Wyjąłem kartę, w komputerze popełniłem backup przez obraz partycji, następnie fsck (były błędy) i przy okazji zdjąłem journal z ext4. Podziałało jeszcze parę dni i sytuacja znowu się powtórzyła. Tym razem sprawdziłem dokładniej. Badblocks widzi błędy na karcie, zarówno na teście odczytu (jeden), jak i niedestrukcyjnym teście zapisu (więcej). Próbowałem reanimować przez oznaczenie przez fsck sektorów jako uszkodzonych (patrz przydatne polecenia Linux), ale bez powodzenia. Po naprawie rpi już się nie bootuje z tej karty.

Nie jestem w stanie stwierdzić, czy winien był – niestety domyślnie w Raspbianie włączony – journal, czy zapisywanie przez transmission stanu co kilkanaście minut na dysk (kartę) gdzieś w /var. Symlinka i przenoszenia na dysk twardy nie robiłem. Po pierwsze i tak system był z journalem, po drugie, chciałem zobaczyć, na ile to szkodliwe dla karty. Jak widać jest szkodliwe i karta potrafi paść w mniej niż pół roku. Co prawda widzę karty Goodram 4 GB za ok. 10 zł, ale nie widzę sensu w grzebaniu i ew. utracie danych.

Niebawem, po kupnie karty (tak się pechowo składa, że nic wolnego większego niż 2 GB chwilowo pod ręką nie mam), wskrzeszę system. Być może kupię docelowy dysk do kieszeni i wtedy zrobię od razu root montowany w trybie read only. Nawet jeśli nie, to od razu po instalacji zdejmę journal z ext4, prawdopodobnie zajmę się też od razu transmission…

Kiedyś pojawią się tu zdjęcia – leżą na dysku, który był podłączony do NAS, a nie chce mi się podłączać go bezpośrednio do kompa…

[1] Bo router to WRT54GL, który co prawda linkuje się na 54 Mbit bezprzewodowo, ale realnie komputery wyciągają ok. 20 Mbps. Po wpięciu na kablu nie ma problemu. W eterze umiarkowany syf, wybrany najlepszy kanał i tryb G only. Ogólnie 802.11n by się przydało, ale przecież router działa, a szczerze mówiąc nie sądzę, bym zobaczył różnicę – 20 Mbps to kosmos. Chociaż znajomi donoszą, że przy 802.11n poprawia się zasięg, więc pewnie się skuszę…

[2] Żadne tam nielegale, po prostu mały wkład w projekty open source. Seedują się netiso Debiana (trzy architektury), pierwszy CD Debiana (trzy architektury), t(a)ils, tego typu sprawy. Zresztą pisałem o tym już (uroki niechronologicznego publikowania notek).

UPDATE: W jednej z kolejnych notek opisuję, jak zrobić z maszynki z Linuksem router GSM/Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Raspberry Pi nadaje się do tego bardzo dobrze.