Uruchomienie karty Wi-Fi Mediatek MT7601U na Banana Pi

Jakiś czas temu kupiłem małe, tanie karty USB Wi-Fi w Chinach. Stwierdziłem, że przydadzą się do niewyposażonych we wbudowane karty płytek z ARM, czy nawet żeby któryś komputer podpiąć na szybko do sieci Wi-Fi w standardzie N. Karty przetestowałem na szybko na laptopie i wszystko było fajnie, ale… uruchomienie ich wymagało rzeźby i dokompilowania modułu. Dla jasności: chodzi o karty, które sprzedawane są jako Mediatek MT7601U USB bgn WiFi dongle.

Po podłączeniu w wyniku lsusb widać:

Bus 002 Device 002: ID 148f:7601 Ralink Technology, Corp.

 

a wymagany driver dla tej karty to mt7601u. W momencie podłączania karty USB w dmesg pojawia się:

[ 1075.027898] usb 2-1: new high-speed USB device number 2 using ehci-platform
[ 1075.189356] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
[ 1075.196330] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1075.203764] usb 2-1: Product: 802.11 n WLAN
[ 1075.208160] usb 2-1: Manufacturer: MediaTek

 

Dziś potrzebowałem uruchomić Banana Pi pod kontrolą dystrybucji Bananian z tą kartą, wetknąłem ją w lapka, żeby odświeżyć sobie budowanie modułu i… miło mnie zaskoczył – działało od kopa. Stwierdziłem, że może zasługa nowszego kernela (4.5), ale prawdopodobnie nie – brakujący firmware jest dostarczany w Debianie w pakiecie firmware-misc-nonfree. Niedostępnym w Jessie, ale nie jest to wielki problem. Poniżej krótka instrukcja, co zrobić, żeby zadziałało (dla Bananiana 16.04 (released 2016-04-23)). Być może zadziała także na starszym kernelu, ale nie testowałem. Zgodnie z tym, co piszą na GitHubie projektu, driver jest dołączony do mainline kernela, i opisany poniżej sposób powinen działać dla kerneli od 4.2 w górę.

Instalacja kernela z linii 4.x na Banana Pi (niezalecana w FAQ Bananiana, ale…):

wajig install linux-image-4.4-bananian

 

Następnie reboot, by Banana Pi działało z nowym kernelem. Kolejnym krokiem jest pobranie pakietu z firmware dla karty:

wget http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-misc-nonfree_20160110-1_all.deb

 

Usunięcie pakietów, które konfliktują z ww. pakietem (oczywiście wajig; wykonać dla wszystkich pakietów, które zgłoszą konflikt):

wajig remove firmware-ralink

 

Ostatnim krokiem jest instalacja pobranej paczki:

wajig install firmware-misc-nonfree_20160110-1_all.deb

 

Od tej pory karta USB Mediatek powinna po prostu działać po włożeniu do USB. Oczywiście należy połączyć się jeszcze z siecią bezprzewodową, ja polecam do tego wicd i wygodny konsolowy wicd-curses. Zadziała także dla Debiana w wersji stable (Jessie) – w zasadzie Bananian różni się tylko kernelem.

UPDATE Dobrzy ludzie słusznie donoszą, że firmware-misc-nonfree jest w repozytorium backports, więc instalacja jest prostsza – wystarczy dodać stosowne repozytorium do źródeł. Przyznaję, że nie sprawdzałem, bo jakoś mi się błędnie zakodowało, że ani armel, ani armhf nie są dostępne w backports.

KVM i task blocked for more than 120 seconds – solved

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa, niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami:

kernel: INFO: task XXX blocked for more than 120 seconds.kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo – potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana, ale w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn – pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało, ale przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu – widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt – problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi… Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów – wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że… to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej – góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce – a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i… trafiony, zatopiony – wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale… problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.

Boot once w GRUB

Czasami jest potrzeba, żeby uruchomić maszynę z danym kernelem, ale tylko raz. W przypadku niepowodzenia chcemy mieć uruchamiany z powrotem stary, sprawdzony kernel. Zwykle taka potrzeba pojawia się, gdy testujemy nowy kernel i nie mamy fizycznego (lub zbliżonego) dostępu do maszyny, a np. mamy pod ręką kogoś, kto w razie problemów niekoniecznie pomoże z debugiem, ale chociaż wciśnie reset. Dziś pojawiła się u mnie taka potrzeba, za sprawą dedyka pod Piwika i chęci zmiany kernela z nieco starego z OVH na dystrybucyjny.

Okazało się, że wypadłem z tematu. Ostatni raz miałem potrzebę jednorazowego uruchomienia kernela chyba w okolicach LILO jako używanego bootloadera. Nie pamiętam jak to dokładnie w LILO wyglądało, ale mam wrażenie, że było proste, intuicyjne (w końcu jeden konfig) i – przede wszystkim – dobrze udokumentowane.

Poszukałem chwilę i znalazłem polecenie grub-reboot, któremu jako parametr podaje się numer wpisu w /boot/grub/grub.cfg i które ma powodować jednokrotne uruchomienie kernela o podanym wpisie. Ucieszyłem się, że pomyśleli o mnie i tak prosto. Maszynka niekrytyczna, kernel dystrybucyjny, więc raczej wstanie, wydałem więc stosowne polecenie, następnie reboot i… system wstał! Ze starym kernelem.

Nawet niezbyt się zirytowałem. Po prostu odpaliłem testowego kompa w domu i zacząłem się bawić. Ustawiam numer wpisu, który ma się włączyć, reboot i… to samo. Dłuższa chwila szukania i znalazłem opis na niezawodnym wiki Arch Linux:

This requires GRUB_DEFAULT=saved in /etc/default/grub (and then regenerating grub.cfg) or, in case of hand-made grub.cfg, the line set default=”${saved_entry}”.

Jak na lata doświadczeń przystało, wyboru kernela nie pozostawiam przypadkowi i w moim /etc/default/grub były ustawione na sztywno numery kerneli do uruchomienia. Zmieniam na powyższe na testowej maszynie w domu, grub-reboot potem reboot i… wstał! Z nowym kernelem. Świat wydaje się piękny, więc reboot, by wrócić na stary kernel i… tak dobrze nie ma. Uruchamia się za każdym razem z nowym.

Nawet niezbyt się zirytowałem, po prostu rebootnąłem zdalną maszynkę na nowy kernel. Skoro dystrybucyjny to raczej wstanie. Stosowne zmiany, reboot i… maszynka wstała, z nowym kernelem, wszystko wydaje się działać. Misja zakończona, cel osiągnięty.

I tu byłby koniec wpisu, ale w międzyczasie zacząłem rozmowę na ten temat na kanale IRC #debian (@freenode). Tam dowiedziałem się o /boot/grub/grubenv i o tym, że może (będzie) się tak dziać, jeśli nie jest ustawione prev_saved_entry. I faktycznie, nie było. I dowiedziałem się, że można to ustawić wydając polecenie grub-reboot więcej, niż raz.

Czyli, żeby zrobić boot once dla GRUBa, trzeba kolejno:

  • ustawić GRUB_DEFAULT=saved w /etc/default/grub
  • grub-reboot <wpis, gdzie ma być default>
  • grub-reboot
  • sprawdzić /boot/grub/grubenv na wszelki wypadek
  • reboot

I pomyśleć, że przy LILO była to szybka edycja konfiga plus lilo dla wprowadzenia zmian w życie… Znaczny postęp poczyniliśmy! 😉

Skoro już wpis na tematy linuksowe… Archa nie próbowałem, ale ludzie (w tym jeden DD) chwalą. Bardzo dobra dokumentacja. Poza tym, jest taka inicjatywa jak debianfork.org. I cieszę się, że jest. Bo skoro Debian może mieć więcej niż jedną architekturę, więcej niż jeden kernel (tak kFreeBSD), to czemu nie miałby móc mieć różnych, równorzędnych demonów do startu usług?

Dostępne wszystkie kody źródłowe dla Banana Pi

Developerzy postąpili zgodnie z zapowiedziami i udostępnili wszystkie kody źródłowe do Banana Pi. Są pierwsze doniesienia na forum o sukcesach z akceleracją GPU oraz potwierdzenia, że karta sieciowa działa na 1 Gbps na otwartym sterowniku. Nieoficjalnie słyszałem o prędkościach 520 Mbits/sec i 697 Mbits/sec (iperf; zależy czy serwer czy klient na bpi). Jak widać więcej, niż maksymalna przepływność USB. Czyli Raspberry Pi ma się coraz bardziej czego obawiać.

Biorę się do klonowania repozytoriów. 😉

Jak uruchomić touchpad na Dell Vostro 3360 pod Linuksem

Dell Vostro 3360 to zacny sprzęt, z którego korzystam w pracy, chyba od roku. Trochę żałuję, że nie kupiłem go do domu, ale kupowałem wcześniej, nie byłem jakoś przekonany do 13″, no i cena też trochę wyższa. Okazuje się, że jak najbardziej taki ekran daje radę. W pracy korzystam z wersji z dyskiem SSD i procesorem i5. Na początku było więcej, teraz jest 4,5-5h na baterii, więc wynik bardzo przyzwoity – długie wypady pociągiem, serie spotkań w firmie czy przedłużający sie wypad do kolokacji mu nie straszne i nie ma potrzeby korzystania z zasilacza.

Vostro 3360 daje się zmusić do działania z Linuksem (opis co jak działa może kiedyś popełnię, ale wcześniejsze opisy na potrzeby Linux on laptops nie cieszą się zainteresowaniem, więc motywacja jest nikła), ale nie jest to sprzęt, w którym wszystko działa OOTB. Nawet więcej: dawno nie widziałem sprzętu wymagającej takiej rzeźby w celu uruchomienia Linuksa. Grymasił na wersję kernela, co objawiało się… zwisami systemu (nic ciekawego w logach nie znalazłem). Co ciekawe tylko pod Debianem, kumple pod Ubuntu z IIRC taką samą wersją kernela problemu nie mieli. Na debianowym 3.6 (wówczas z experimental) działało stabilnie, więc tak zostało.

Inne problemy to: touchpad (naciśnięcie obu klawiszy naraz domyślnie nie emuluje naciśnięcia środkowego klawisza, co jest standardowym pod Linuksem – i ukochanym przeze mnie – skrótem do wklej), dźwięk czy karta sieciowa Atheros (o dziwo miedź). Dźwięk z alsą z Wheezy’ego działa IIRC od kopa, więc można uznać problem za załatwiony. Zresztą uruchomienie wszystkich komponentów Vostro 3360 na Linuksie (Debian Wheezy) ładnie opisał Łukasz. Co ciekawe, kernel 3.7 powodował jakieś problemy, ale nie pamiętam, czy chodziło o stabilność, czy może o coś innego.

W każdym razie czasy się trochę zmieniły, 3.6 jakiś taki starawy już. Doszły mnie słuchy, że karta sieciowa powinna działać bez magicznych zabiegów pod kernelem 3.11. Postanowiłem sprawdzić. Faktycznie, wydaje się działać. A system pozostaje stabilny. Pozostał jednak problem z touchpadem, więc postanowiłem zrobić instrukcję dla nowszej wersji kernela i nowszych plików ze strony, bo takie się pojawiły.

Na początek smutna sprawa: kernel 3.11, a dokładniej jego pliki nagłówkowe wymagają gcc w wersji 4.8, a to oznacza wymianę połowy systemu ze względu na zależności. Albo konieczność skompilowania kernela samodzielnie (czego na potrzeby desktopa wieki nie robiłem). Wybrałem bramkę numer dwa.

Wchodzimy na http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/view i pobieramy plik psmouse-alps-1.3-alt.tbz.

Rozpakowujemy go (w /usr/src)

tar xvjf psmouse-alps-1.3-alt.tbz

Pobieramy debianowe źródło kernela

wajig install linux-source-3.11

I kopiujemy bieżący konfig (zakładam, że mamy uruchomiony kernel 3.11 z Debiana)

cp /boot/config-3.11-2-amd64 /usr/src/linux-source-3.11/.config

Kompilujemy i paczkujemy kernel oraz pliki nagłówkowe

cd /usr/src/linux-source-3.11
make-kpkg --append-to-version=-bpo-rozie --initrd kernel_image
make-kpkg --append-to-version=-bpo-rozie kernel_headers

Instalujemy utworzone pakiety

cd .. && wajig install linux-image-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb && 
wajig install linux-headers-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb

Kompilujemy i instalujemy odpowiedni moduł:

cd /usr/src/psmouse-alps-1.3 && ./alps.sh dkms_build_alps

Polecenie to automatycznie powoduje przeładowanie modułu psmouse, więc jeśli nie wystąpiły błędy, to od tej chwili wszystko powinno działać poprawnie, w szczególności naciśnięcie obu przycisków touchpada powinno wklejać zawartość schowka.

UPDATE: Prawdopodobnie da się prościej, o ile się nie jest ślepym. Wystarczy do sources.list dodać obsługę backportów dla Wheezy’ego:

deb http://http.debian.net/debian wheezy-backports main contrib non-free

i dostępne staną się kernele linux-image-3.11*… Cóż, kto nie ma w głowie, ma w… kompilatorze. Inna sprawa (i moje usprawiedliwienie!) to fakt, że nie tylko nikt nie zwrócił na to uwagi w komentarzach, ale nawet dwie osoby korzystają z mojego kernela.

UPDATE2: Wygląda na to, że od wersji 3.13 kernela nie potrzeba takich zabiegów. Przed chwilą zainstalowałem z debianowych backportów 3.13.5-1~bpo70+1 i… touchpad działa od kopa, bez kompilacji czegokolwiek.

Alternatywa dla VirtualBox – AQEMU.

Zachciało mi się zmiany kernela z 3.2 na 3.5. Inspiracją był znajomy, który zaobserwował spadek zużycia prądu na laptopie przy zmianie z kernela 3.2 do 3.4 z 28W do 19W (pomiar wg powertop). VirtualBox po zmianie kernela oczywiście przestał działać. Nic nowego i nawet pisałem o tym, że debianowa paczka dla VirtualBox jest pod konkretny kernel robiona. Pisałem też, jak uruchomić VirutalBox na Debianie z własnym kernelem.

Co prawda u mnie kernel 3.5 nic nie daje w kwestii zużycia energii, ale skoro już pojawił się temat, to trzeba go pociągnąć. Mogłem użyć poprzednio opisanego sposobu z uruchomieniem VirutalBox na Debianie z własnym kernelem, ale jakoś nie uśmiechała mi się zmiana VirtualBox na wersję z repozytorium Oracle (poza tym, kiedyś różniły się licencją – w Debianie było OSE, nie żeby miało to jakiekolwiek znaczenie w tym przypadku), ściąganie plików nagłówkowych i kompilacja kernela, więc postanowiłem się rozejrzeć za alternatywami dla VirtualBox.

Ludzie podszepnęli KVM, który jak najbardziej znam i używam, ale w innym, serwerowym zastosowaniu. Okazuje się, że KVM ma także, obok narzędzi do zarządzania CLI i webowych, także narzędzia desktopowe, czyli GUI. Na stronie z listą frontendów dla KVM znaleźć można trzy frontendy typu desktop: AQEMU, virt-manager oraz GKVM. W pierwszym podejściu przeoczyłem virt-managera i wziąłem się za AQEMU. Już miałem orzec, że bootowanie z obrazu iso płyty CD nie działa, ale dogrzebałem się do ustawienia, które pozwala wybrać medium (i które nie jest zapamiętywane, bug zgłoszony).

Po tym było już z górki. Wirtualizacja desktopu z użyciem KVM generalnie po prostu działa. Nie testowałem jakoś specjalnie mocno, bo służy mi to głównie do zabaw z różnymi systemami liveCD, ale sieć działa, bootowanie z CD-ROM działa, przeglądarka działa. Zarządzanie, wygląd i dostęp do opcji też wygląda też sensownie, co można zobaczyć na screenshocie poniżej.

AQEMU screenshot

Źródło: strona projektu AQEMU

Zrobiłem, po przebootowaniu do 3.2, rzecz jasna, krótki benchmark, a w zasadzie namiastkę benchmarku, dla AQEMU i VirtualBox, w postaci zmierzenia czasu uruchamiania systemu z liveCD (padło na T(A)ILS – akurat nowe wydanie jest; 1GB RAM dla wirtualki, 1 CPU, parę uruchomień, ustawienia zbliżone do domyślnych). Dla AQEMU bootowanie (do momentu pierwszej interaktywności) trwało zwykle 44,9 sekundy, dla VirtualBox – 45,2 sekundy. Różnica pomijalna. Co ciekawe, dołożenie drugiego procesora nie wpływa na wynik i to w żadnym z przypadków.

Przy okazji, gdyby ktoś się brzydził frontendami i był hardcore’owym użytkownikiem wiersza poleceń, to do uruchomienia liveCD z w pliku o nazwie plik.iso użyciem KVM wystarczy:

kvm -m 1024 -vga vmware -boot d -cdrom plik.iso

Chwilowo to wszystko nt. wirtualizacji na desktopie. Szybki wniosek VirtualBox nie jest jedynym rozwiązaniem, AQEMU daje radę i wygląda na rozwiązanie wygodniejsze, jeśli ktoś używa Debiana niekoniecznie z dystrybucyjnym kernelem, lub kernelem z innej wersji. Nie będę testował GKVM – projekt wygląda na porzucony. Prawdopodobnie niebawem szansę dostanie virt-manager – na razie nie uruchomił się OOTB i krzyczy o niemożności dostania się do libvirtd. Nie miałem czasu bliżej się przyjrzeć sprawie. Jak uruchomię, to nie omieszkam opisać. Stay tuned.

Seagate Dockstar jako router.

Jakiś czas temu było o HP T5520 jako routerze, który działał i byłem z niego zadowolony, ale trzeba poznawać nowe rzeczy (w tym przypadku: sprzęt na ARM). Poza tym, z T5520 można zrobić nieco więcej, niż tylko router (ma wyjście audio, w połączeniu z MPD będzie pewnie robił za odtwarzacz radiowy, shell i NAS w innej lokalizacji). Jasne, mogłem dołożyć do Dockstara kartę dźwiękową na USB, ale ciekawiło mnie też, czy modem USB (Sagem F@st 800) zadziała na ARM.

Wybór padł na Seagate Dockstar, bo był to tani sprzęt (wówczas ~100 zł, obecnie dwa razy drożej), o niezłych parametrach (128 MB RAM, procesor 1,2 GHz). Jako alternatywa dla T5520 w tym zastosowaniu – teoretycznie idealny. I – z racji architektury ARM – znacznie bardziej energooszczędny (maksymalnie poniżej 10W poboru prądu). Last but not least – Dockstar obsługuje niemodyfikowanego Debiana.

Od zakupu do uruchomienia minęło sporo czasu. O ile instalacja Debiana była bezproblemowa, o tyle działało to nieco losowo, więc dwa podejścia spędziłem na ustalaniu, co się sypie, że czasem wstaje z Debianem, a czasem z oryginalnym systemem. W końcu doszedłem, że winny był pendrive. Faktycznie, po wymianie na inny zaczęło działać stabilnie i można było się zająć przeniesieniem konfiguracji.

Przeniesienie było proste, podłączenie modemu i… zonk. Okazało się, że debianowe kernele nie są równe, konkretnie brakowało modułu br2684. Niby żaden problem przekompilować kernel, ale jeśli mam to robić na niedużym pendrive zamiast dysku, albo crosskompilując, to tak różowo nie jest. Ostatecznie zgłosiłem błąd dotyczący braku br2684, który szybko został poprawiony.

Niestety, poprawka wyszła dla kernela w wersji 3.0 z experimental. Jakoś nie ciągnęło mnie do wrzucania na produkcyjną (choć prywatną) maszynkę takiego wynalazku, tym bardziej, że nie sam kernel trzeba wymienić. A cokolwiek innego wiązało się z kompilacją… No dobrze, niech będzie. Skoro już kompilować, to jednak 2.6 ze Squeeze. I natywnie, na Dockstarze (jakoś się na tym pendrive zmieściło po rozpakowaniu).

Pobrane źródła, pobrane i nałożone patche, korekta pliku konfiguracyjnego, make-kpkg… I zonk z kryptycznym komunikatem (niestety nie zanotowałem). Okazuje się, że make-kpkg nie potrafi sam wykryć architektury, na której jest uruchamiany. Po podaniu –arch armel (dzięki przewodnikowi po crosskompilacji dla Dockstara) poszło dalej, choć niewiele. Tym razem winne lzma i cannot allocate memory (OSLT; mimo sporego swapa – IIRC 160 MB) i tyle. A przecież nie tak dawno kompilowałem kernele na maszynach z 64 MB RAM…

Na szczęście ww. przewodnik po crosskompilacji ładnie opisuje jak stworzyć środowisko i krok po kroku wyjaśnia, jak zrobić kernel. Stwierdziłem, że skoro akcja pewnie będzie się powtarzać, to warto mieć coś szybszego do kompilacji… Opis jest bdb, używanie środowiska do crosskompilacji proste. Wystarczyło poczekać parę h (tak, kernel debianowy to krowa z masą zbędnych opcji, ale stawiałem na kompatybilność i nie chciałem się bawić…) i kernel gotowy.

Kolejna ARMowa ciekawostka to instalacja. Zwykłe dpkg -i nie wystarcza. Jak widać w przewodniku po crosskompilacji kernela, trzeba jeszcze odczynić ręczną magię z uImage i uInitrd. Z pozytywów: wstało od kopa. Jest moduł, ale… nadal nie działa. Tym razem po podłączeniu modemu masa wpisów w stylu:

ATM dev 0: usbatm_submit_urb: urb 0xc6c50b40 submission failed (-28)!

Oczywiście modem się nie łączy… Googlanie po całości wpisu nie dało efektów, ale ostatecznie, szukając po fragmentach, trafiłem na ten błąd dla OpenWRT, który sugeruje wymuszenie bulk mode. Niby wolniejsze przy większych prędkościach, ale dla łącza 1 Mbps nie stanowi. Zresztą, innych pomysłów brak, zatem:

echo "options ueagle-atm altsetting=0,0,0,0" > /etc/modprobe.d/eagle-usb.conf

W końcu działa. Nawet się połączył. Małe dopieszczenie konfigów i w końcu maszynka przeniesiona. Generalnie z odkrytych wad Dockstara: nie ma RTC, więc po restarcie startuje bez aktualnej daty i godziny. Oczywiście instalacja ntp załatwia problem po nawiązaniu łączności z Internetem, ale przy ppp chwilę to trwa i przez tę chwilę wpisy w logach będą ze złą datą.

Inna uwaga odnośnie Debiana i ARM: nie jest to tak dopracowane jak architektury i386 i amd64. Generalnie działa, ale zamiast po prostu działa, trzeba bawić się w podawanie opcji (make-kpkg) lub nawet robienie części rzeczy ręcznie (initrd).

Parę przydatnych/użytych linków, niekoniecznie występujących w treści:

Wiki Debian on Dockstar

Zgłoszenie błędu z modemem USB dla OpenWRT

Komunikaty błędu na Dockstarze dotyczące Sagem F@st 800

Opis przygotowania środowiska do crosskompilacji i zrobienia nowszego kernela dla Dockstara

Póki co, trwa niezbyt obiecująco wyglądające (wygląda, że raz się wywalił z powodu loadu…) wygrzewanie sprzętu.

UPDATE: Jednak działa stabilnie od blisko dwóch tygodni. Prawdopodobna przyczyna ww. wywałki – błędy filesystemu (pewnie z czasu instalacji, kiedy nie był read only jeszcze). Po fsck, naprawieniu błędów i reboocie bez problemu.

UPDATE2: W jednym z kolejnych wpisów opisuję jak zrobić na Linuksie router Wi-Fi. Po dołożeniu karty Wi-Fi na USB Dockstar się nada.

Grub2, memmap i problemy z upgrade do Squeeze.

Ostatni upgrade systemu (z prywatnych, głównie desktopy) do Squeeze’ego zakończony. Zasadniczo bez zgrzytów, poza tym, że wyglądał trochę inaczej niż inne, a pakietów było mnóstwo. Naprawdę mnóstwo, apt-cacher wiele nie pomógł, choć inny desktop też z niego korzysta. KDE4 robi swoje, niestety. Łącze 1Mbps to przeżytek. No i jeszcze szopka z upgrade do grub2 była.

Desktop ma uszkodzony RAM, więc korzystam ze sposobu na uszkodzoną pamięć RAM, który opisywałem wcześniej. W grub miałem wpis:

/boot/vmlinuz-2.6.32.11 root=/dev/hda2 ro memmap=2M$311M

Przy dist-upgrade wszytko wykrył poprawnie, łącznie z dodatkowymi opcjami. Oczywiście skorzystałem z proponowanej opcji chainload (i całe szczęście…). Po reboocie wchodzę do grub2, tam wybieram nowy kernel (dystrybucyjny) i… reboot. Bez żadnego komunikatu. Niefajnie. Niestety to samo powtórzyło się przy wybraniu z grub2 kernela własnej roboty, którego używałem na Lenny.

Za to – ku mojemu zdziwieniu – ze starego gruba nowy kernel zadziałał. Co ciekawe, w przeciwieństwie do wersji z Lenny’ego, obsługiwał poprawnie wpis dla memmap – przy szybkim teście podlinkowanym wyżej nie było błędów.

Chwila zabawy i jasne było, że coś się skopało. Zamiast memmap=2M$311M było widoczne… memmap=2M11M. WTF? A po usunięciu opcji memmap wszystko ładowało się poprawnie (tyle, że korzystając ze skopanego obszaru RAM). Chwila googlania i wydało się, że do /etc/default/grub trafiła linia

GRUB_CMDLINE_LINUX="memmap=2M$311M"

która po przetworzeniu przez *sh będzie faktycznie wyglądała tak, jak wyglądała, bo $3 zostanie uznane za zmienną… Grub2 dodatkowo wymaga w swoim menu postaci memmap=2M\$311M czyli ostatecznie poprawna wersja w pliku /etc/default/grub to:

GRUB_CMDLINE_LINUX="memmap=2M\\\$311M"

Jutro zgłaszam buga.

Jak bezpiecznie korzystać z uszkodzonej pamięci RAM bez BadRAM.

BadRAM był fajny, ale jest nieutrzymywany. Ostatnią działająca u mnie wersja była do kernela 2.6.25.x, późniejsze, choć istniały (np. dla 2.6.29), to nie udało się ich – wbrew wcześniejszej radości – zmusić do poprawnego działania – nadal pojawiały się błędy np. na liczeniu sum kontrolnych.

Winny w tej maszynie jest ewidentnie RAM, co zostało już dawno stwierdzone, ale maszyna na tyle niekrytyczna, że inwestować się nie opłaca (poza tym, szkoda środowiska), a ze starszym (tj. 2.6.25.x) kernelem spokojnie i poprawnie działa. Poza tym, przecież to Linux, więc da się poprawić. I jaki uroczy temat do notek jest. 😉 Z okazji świątecznej wizyty w domu, postanowiłem jednak zerknąć, czy nie pojawiły się patche BadRAM do jakichś nowszych kerneli (serii 2.6.3x, znaczy).

Nie pojawiły się, ale zamiast tego, trafiłem na pierwszej stronie wyników na sposób radzenia sobie z uszkodzoną pamięcią pod Ubuntu, który w ogóle z BadRAM nie korzysta. Chwilę później trafiłem na ten wpis. Okazuje się, że za pomocą parametrów, które można przekazać kernelowi, w szczególności mem=XX oraz memmap=X$YY, można wyłączyć obszary pamięci z użytkowania, co przekłada się w praktyce, na możliwość bezpiecznego korzystania z uszkodzonej i dotychczas powodującej błędy pamięci. Więcej o parametrach w kernelowym Documentation/kernel-parameters.txt, ale na potrzeby tego zagadnienia wystarczą te dwa.

Pierwszy parametr (mem=) ogranicza wykorzystaną pamięć. Jeśli uszkodzenie jest w okolicy 312 MB (memtest+ prawdę powie), to mem=310M co prawda obniży dostępną pamięć do 310 MB, za to system będzie działał bez problemów. Tyle tylko, że stracimy 200 MB pamięci. Trochę sporo, zwłaszcza, jeśli całość do dyspozycji to tylko 512 MB.

Drugi (memmap=) jest ciekawszy, bo rezerwuje X pamięci od adresu YY. Przykładowo memmap=10M$305M oznaczy pamięć od  305 MB do 315 MB jako wykorzystaną. Czyli stracimy raptem 10 MB, a zyskamy niezawodny system. Tyle teorii. W praktyce na dystrybucyjnym 2.6.26 z Lenny’ego, mem=300M działało poprawnie (najprościej sprawdzić przez free -m), natomiast memmap=10M$305M był radośnie olewany – nadal pokazywało dostępną całą pamięć.

Przyczyny tego stanu rzeczy nie udało mi się ustalić (podejrzewam limit 4GB zamiast 1GB, błąd w kernelu lub korzystanie z initrd – jeśli ktoś zna odpowiedź, to proszę o info), natomiast skompilowanie własnego 2.6.32.2 na podstawie konfiga od 2.6.25.x (z którego spatchowanego BadRAM korzystałem do tej pory) rozwiązało problem – memmap=2M$311M, czyli wyłączenie tylko 2 MB spowodowało, że system działa poprawnie.

Ponieważ najłatwiej zaobserwować błędy było dotychczas na sumach kontrolnych, to testowanie wykonałem prostym skryptem (brzydki bash napędzany perlem – pewnie dałoby się prosto przespisać na gołego basha, ale kto tam ma czas…; skrypt na końcu wpisu). Stosunkowo duży plik (większy, niż dostępna pamięć RAM, mój tworzony przez dd if=/dev/urandom of=random.dat bs=1MB count=1024), z losową zawartością (tworzony raz, bo czasochłonne), liczenie sum kontrolnych. Jeśli błąd pojawi się w buforze dyskowym, to przy braku wielkiego pecha suma kontrolna będzie się różnić przed i po skopiowaniu. Zapuszczone w pętli, z logowaniem do pliku – nawet przy uszkodzonej pamięci nie wystarczy 1 przebieg – błąd nie pojawia się za każdym razem. Natomiast choćby jeden błąd oznacza, że coś jest nie tak jak być powinno.

Podstawą jest jednak free -m. Jeśli on nie widzi mniej pamięci, to można nie zaczynać nawet ze skryptem.

Jeśli po dłuższym teście brak błędów (pojedynczy błąd oznacza, że nie jest dobrze), to wystarczy dopisać linię do konfigu gruba, by przy każdej aktualizacji kernela dodawał do parametrów określony argument:

#kopt=root=/dev/hda2 ro memmap=2M$311M

Dzięki temu możemy korzystać z dowolnej (najnowszej!) wersji jądra, bez upierdliwego patchowania (cóż, patche badram były dość kijowe, włączenie z tym, że zdarzało im się mieć literówki uniemożliwiające kompilację).

Na koniec wspomniany skrypcik:

#!/usr/bin/perl
$src="/random.dat";
$dst="/tmp/memtest_tmp.dat";
$log="memtest_copy.log";
if (-f $dst){
   system (" rm $dst ");
}
system (" date >> $log ");
while (1){
  system (" cp $src $dst ");
  $res = `md5sum $dst`;
  $res2 = `sha1sum $dst`;
  $res_ = `md5sum $src`;
  $res2_ = `sha1sum $src`;
  $check = "ERROR";
   if (($res == $res_) && ($res2 == $res2_)){
     $check="OK";
   }
system (" echo \"$check $res $res_ $res2 $res2_ \" >> $log ");
system ("rm $dst");
}

Podsumowując: żegnaj BadRAM!

Virtualbox i własny kernel

Krótkie howto jak w Debianie Lenny korzystać z własnego kernela (tu: 2.6.30.5) i Virtualbox.

W związku z remasteringiem Knoppiksa na potrzeby Anonymiksa zainteresowałem się bliżej rozwiązaniami do wirtualizacji. Kiedyś (3 lata temu?) korzystałem z VMware Playera, który idealny nie był – trochę za sprawą licencji, trochę za sprawą tego, że nie do końca pozwalał na tworzenie własnych obrazów (dało się, z użyciem qemu IIRC), a i z bootowaniem z CD było trzeba powalczyć. Z kolei remastering Knoppiksa na fizycznej maszynie jest jak najbardziej wykonalny, ale niewygodny – rebooty, uruchamianie Knoppiksa itd. Aż się prosi o wirtualizację.

Sporo dobrego słyszałem ostatnio o Virtualbox. Niestety, wersja w Debianie zrobiona jest pod konkretny kernel. Ponieważ znajomi korzystają, postanowiłem się zapytać, w jaki sposób. Okazuje się, że nie korzystają z wersji dystrybucyjnej, a z wersji bezpośrednio od producenta, czyli przez dodanie

deb http://download.virtualbox.org/virtualbox/debian lenny non-free

do /etc/apt/sources.list, a następnie apt-get install virtualbox-3.0. Tyle, że także korzystają z dystrybucyjnego kernela, co mnie szczerze mówiąc zdziwiło, bo lapek i dystrybucyjny kernel jakoś mi ze sobą nie pasują (nie żeby nie działało, bo działa). Albo ja po prostu jestem dziwny i lubię mieć nowe i na miarę (I, ricer), albo jeszcze mam czas na takie zabawy. 😉

W każdym razie korzystanie z dystrybucyjnego kernela wydało mi się nieporozumieniem niemal takim nieporozumieniem, jak praca na fizycznej maszynie i rebooty (tak, wiem, przesadzam). FAQ na stronie i dokumentacja na pierwszy rzut oka nie przewidują takiej możliwości, więc poszukałem rozwiązania ma własną rękę (pomoc na IRC jest przereklamowana). Nie pamiętam słów kluczowych do wyszukiwarki, ale ostatecznie trafiłem na ten wpis (dead link). Rozwiązanie jest – jak widać – bardzo proste.

Dla porządku, dla niespikających: należy pobrać paczkę .deb właściwą dla naszego systemu ze strony producenta i zainstalować ją (apt-get install pakiet.deb). Podczas instalacji, wykryty zostanie brak modułu i zostaniemy zapytani, czy chcemy zbudować tenże moduł dla aktualnie działającego kernela. Wymagane są oczywiście źródła (headers?) w /usr/src i narzędzia do kompilacji kernela (zakładam, że jak ktoś ma custom kernel, to wie, co potrzebne). Wadą rozwiązania jest konieczność pamiętania o dpkg-reconfigure virtualbox po każdej zmianie kernela w celu zbudowania modułu dla nowej wersji. Dla 2.6.30.5 działa bez problemu.