Solaar – parowanie urządzeń bezprzewodowych Logitech

Urządzenie bezprzewodowe podłączane do komputera składa się z właściwego urządzenia, oraz odbiornika, podłączanego do komputera. Ten ostatni jest niewielki, przez co łatwo go zgubić. Bywa też, że w środowisku, gdzie podobnych urządzeń jest wiele, urządzenia zostaną zamienione. Z racji częstego przenoszenia, niewielkich rozmiarów urządzeń i braku elementów charakterystycznych, opisywany problem dotyczy raczej myszy bezprzewodowych.

Mysz bezprzewodowa Logitech

Źródło: https://www.mwave.com.au/

Zatem tam, gdzie jest sporo bezprzewodowych urządzeń podobnego typu, na przykład w biurach, często zdarza się, że stopniowo pojawiają się zdekompletowane lub przemieszane zestawy bezprzewodowe. Teoretycznie niesprawne, ponieważ szybki test polegający na włożeniu nowej baterii i podłączeniu urządzenia nie da żadnych efektów – urządzenie nie zadziała ze względu na nieprawidłowe parowanie urządzenia z odbiornikiem.

Jak dowiedziałem się niedawno podczas rozmowy o przydasiach, użytkownicy systemu Linux mają rozwiązanie na tego typu problemy, przynajmniej dla wielu urządzeń firmy Logitech. Istnieje bowiem program Solaar, czyli narzędzie pozwalające na zarządzanie parowaniem urządzeń bezprzewodowych tej firmy.

W przypadku Ubuntu i Debiana wystarczy zainstalować pakiet solaar, a następnie uruchomić program. Użycie jest bardzo proste, wystarczy włączyć urządzenie, które ma być sparowane.

Poza umożliwieniem parowania z dowolnym odbiornikiem tego samego typu, daje ono – na niektórych urządzeniach – dostęp funkcji, do których standardowo nie ma dostępu. Praktycznie dla wszystkich urządzeń pozwala na odczyt stanu baterii (akumulatora!), dzięki czemu można zawczasu przygotować się do wymiany i uniknąć przykrej niespodzianki w postaci niespodziewanego rozładowania.

Dodatkowo program można teoretycznie wykorzystać do zmniejszenia ilości podłączonych urządzeń USB – do jednego odbiornika można przypisać kilka urządzeń, np. mysz i klawiaturę, o ile korzystają z odbiornika tego samego typu. Nie testowałem jednak konfiguracji z podłączonymi jednocześnie kilkoma urządzeniami.

Tak czy inaczej, posiadając „niesprawne” lub zdekompletowane urządzenie firmy Logitech, niekoniecznie warto je od razu wyrzucać, może się ono jeszcze komuś przydać. Jeśli istnieją podobne rozwiązania dla innych systemów, dajcie znać w komentarzach.

Głośniki do laptopa Modecom MC-2009

W pracy, na poprzednim stanowisku, mieliśmy w pokoju głośniki do puszczania muzy. Były to jakieś głośniki marki Logitech, kubaturowo spore, bo każdy miał objętość zbliżoną do dwóch standardowych kubków na kawę. To co było w nich dobre, to całkiem przyjemne brzmienie, szczególnie w porównaniu do głośników laptopowych, które do puszczania muzy na całe pomieszczenie nie nadają się zupełnie. Nawet jakieś doły było słychać, chociaż oczywiście mówimy o odpowiedniku słuchania radia w pracy, nie audiofilii.

Przy przeprowadzce zauważyłem, że owe głośniki nie posiadają dedykowanego zasilacza – miały tylko jeden kabel USB podłączany do laptopa, który – jak się okazało – zapewniał i zasilanie, i transmisję dźwięku. Znaczy danych. Rozwiązanie mi się spodobało i stwierdziłem, że coś podobnego przydało by mi się w domu, bo jednak sensownego rozwiązania audio w domu nie dorobiłem się, a jakość dźwięku z tych głośników z pracy w porównaniu do laptopowych to niebo a ziemia.

Dokładnie tego modelu nie znalazłem (OK, może mieć ładnych kilka lat), całkiem sporo było podobnych, ale dość drogich. Krótkie poszukiwania w sklepach internetowych pokazały jednak, że jest sporo małych (mniejszych od wyżej opisanych Logitechów) głośników do laptopa w zupełnie śmiesznych cenach. Technika poszła do przodu, głośniki przenośne różnej maści potrafią robić robotę zaskakująco dobrze (w porównaniu z laptopowymi, nadal), więc stwierdziłem, że zaryzykuję.

Większość małych ma jednak pewną wadę: do laptopa podłączany jest kabel USB jako źródło zasilania oraz jack audio jako źródło dźwięku. Jeśli czasem przekładamy laptopa, to trzeba odłączać dwie wtyczki, zamiast jednej. Szukałem więc czegoś, co ma tylko jedną wtyczkę i… tak znalazłem głośniki Modecom MC-2009.

Głośniki Modecom MC-2009
Głośniki Modecom MC-2009. Źródło: https://www.manualsearcher.com/

Kosztowały grosze (chyba jakoś dwukrotność najtańszych; 20 zł ), więc natychmiast kupiłem. Przyszły dość szybko, pierwsze co mnie zaskoczyło, to waga. Zdecydowanie cięższe, niż przypuszczałem, co zaliczam na plus – i wskazuje na solidne bebechy, i nie będą latać po biurku, szczególnie, że koty potrafią to i owo trącić, a po biurku chodzą. Z niefajnych rzeczy – kable wyglądają na umiarkowanie trwałe.

W porównaniu do wbudowanych laptopowych znacznie lepszy dźwięk, ot sama średnica głośnika robi robotę. Oczywiście nie ma to porównania do normalnych głośników, natomiast jeśli ktoś używa wbudowanych i niespecjalnie ma miejsce lub potrzebuje przenośnych (ale na kablu, bo oczywiście są też rozwiązania na bluetooth, ale trzeba je jakoś zasilać) – polecam.

Ciekawostka linuksowo-DIY. Po włożeniu identyfikują się następująco:

hid-generic 0003:18C3:6255.0013: input,hidraw0: USB HID v1.00 Device [Elite Silicon USB Audio Device] on usb-0000:00:1d.0-1.3/input2

Sama karta (bo de facto jest to karta dźwiękowa na USB) jest dość popularna, można ją znaleźć w znacznie lepszych głośnikach, więc gdyby siadły, to można wykorzystać do budowy czegoś ciekawszego.

Termometr na USB

Dawno temu byłem zafascynowany prostym układem DS18S20, który działa za pośrednictwem 1-wire i umożliwia dokładny odczyt temperatury przez komputer. Schematów podłączenia przez RS-232 była masa, koszt układu niewielki. Jedyne co powstrzymywało mnie wtedy przed uruchomieniem to… brak realnej potrzeby.

Potem sytuacja się zmieniła – port szeregowy zaczął w komputerach zanikać, a mnie coraz bardziej interesowała
temperatura z wbudowanych czujników (płyta główna, dyski), a nie temperatura otoczenia. Były co prawda schematy jak to podłączyć przez USB, ale w stosunku do pierwowzoru rósł i poziom skomplikowania, i koszt.

Niedawno pojawiła się potrzeba (no dobra, powiedzmy, że potrzeba, bardziej pretekst), więc odświeżyłem temat.
Okazało się, że istnieją tanie moduły PL2303HX USB UART, a także nieco nowsza wersja cyfrowych termometrów, oznaczona symbolem DS18B20. Różnica między wersjami w sumie pomijalna, z perspektywy tego wpisu. Każda z tych rzeczy to ok. 6 zł z dostawą (Allegro), a podłączenie jest jeszcze prostsze i nie
wymaga żadnych dodatkowych elementów, jak widać na schemacie.

Do odczytu temperatury służy digitemp. Opis użycia (zaczerpnięty stąd).

Instalacja pakietu:

apt-get install digitemp

Skanowanie układów:

digitemp_DS9097 -i -s /dev/ttyUSB0

Odczyt wartości:

digitemp_DS9097 -a

Bardziej zależało mi na sprawdzeniu, czy taka prosta wersja faktycznie będzie działać – w wielu miejscach podawane są bardziej skomplikowane schematy. Faktycznie, działa. Rozwiązanie zlutowane na krótko, bez żadnego przewodu ma jednak tę wadę, że moduł PL2303HX grzeje się na tyle, że wpływa na odczyt temperatury. Myślę, że ok. 10 cm kabla załatwi temat, ale gdyby ktoś był zainteresowany to można pomyśleć od razu o kupnie nieznacznie droższej wersji wodoodpornej, z przewodem. Mi akurat zależało żeby kabel się nie pałętał, ale wersję z kablem można zawsze skrócić…

Oczywiście gdyby ktoś chciał całkiem nowocześnie, to teraz czujniki temperatury montuje się do ESP8266 i odczytuje po WiFi. Tyle, że w moim wypadku to niewygodne – problem z zasilaniem, a dane i tak mają trafić do pełnoprawnego komputera, ew. do SoC z Linuksem.

Gdyby ktoś bał się, że blog skręca całkiem w tematy elektroniczne – bez obaw, będzie najwyżej parę wpisów i raczej w ramach wspomnienia o czymś, niż jako podstawowa tematyka.

Huawei E353/E3131 w Debianie

Kiedyś opisywałem uruchomienie Aero2 z modemem Huawei E3131. Kupiłem „taki sam” model i dziś przyszedł. Po podłączeniu do komputera spodziewałem się, że będzie tak samo, jak w poprzednim, ale nie, więc może komuś oszczędzę walki, na którą straciłem dziś dobry kwadrans, jak nie lepiej.

Otóż nowy modem przedstawia się w lsusb:

Bus 002 Device 016: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

Natomiast po wpięciu do portu USB w dmesg widać:

[11264.677637] usb 2-1.2: new high-speed USB device number 15 using ehci-pci
[11264.787001] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[11264.787005] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11264.787007] usb 2-1.2: Product: HUAWEI HiLink
[11264.787009] usb 2-1.2: Manufacturer: HUAWEI
[11264.788426] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[11264.788583] scsi host6: usb-storage 2-1.2:1.0
[11265.736276] usb 2-1.2: USB disconnect, device number 15
[11268.517690] usb 2-1.2: new high-speed USB device number 16 using ehci-pci
[11268.627263] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=14db
[11268.627267] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11268.627269] usb 2-1.2: Product: HUAWEI HiLink
[11268.627271] usb 2-1.2: Manufacturer: HUAWEI
[11268.630336] cdc_ether 2-1.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, 58:2c:80:XX:XX:XX
[11268.707401] cdc_ether 2-1.2:1.0 enx582c80xxxxxx: renamed from eth0

Co prawda świtało mi coś o hilink i zauważyłem kartę sieciową w systemie, ale stwierdziłem, że to tylko jeden z trybów i można używać „po staremu” z /dev/ttyUSB0 i wvdial, który to sposób mam obcykany. Zmyliło mnie też to, że nie mogłem wejść na wskazywany przy opisach wersji hilink adres 192.168.1.1.

Robiłem różne cuda, o których pisać nie będę, na szczęście zapytałem na IRCu i dobrzy ludzie naprowadzili me zawiłe rozumowania na proste tory.

No więc ostatecznie „po staremu” mi się nie udało, natomiast żeby uzyskać adres IP wystarczy wydać polecenie:

dhclient enx582c80xxxxxx

 

I wtedy po wpisaniu w przeglądarkę 192.168.1.1 mamy dostęp do klikalnego interfejsu zarządzania modemem i wszystko działa od kopa.

Niestety, opisy są chyba obliczone albo na ludzi, którzy robią wszystko z ręki, albo na tych, którzy mają wszystko automatycznie. Pobieranie IP z DHCP też.

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.

Jak przenieść aplikację na kartę SD w systemie Android? HOWTO

Na jednym starym urządzeniu z Androidem mam śmieszną ilość wbudowanego dysku w urządzeniu – poniżej 512 MB. Do tego wydawało mi się, że aplikacje ze sklepu Google Play mogą być instalowane tylko na wbudowanym flash w urządzenie. Dziś dowiedziałem się, jak zmusić Androida (przynajmniej poniżej wersji 5) do instalacji oprogramowania bezpośrednio na karcie SD. Operacja jest umiarkowanie prosta, więc jeśli ktoś ma problem z brakiem miejsca na telefonie, to polecam. Co zdziwiło mnie najbardziej to fakt, że nie jest konieczne rootowanie telefonu.

Wymagania

Aby odblokować możliwość przenoszenia praktycznie dowolnego oprogramowania na kartę SD, potrzebne będą:

  • kabel USB do połączenia telefonu i komputera,
  • Android w wersji niższej niż 5,
  • włączenie USB debugging na urządzeniu na czas zmiany ustawień,
  • oprogramowanie Android Debug Bridge (ADB) zainstalowane na komputerze (w przypadku Linuksa powinno być w repozytoriach).

Odblokowanie przenoszenia programów na kartę SD

  • upewniamy się, że tryb USB debugging jest włączony lub włączamy go,
  • podłączamy urządzenie do komputera,
  • sprawdzamy, czy jest widoczne (polecenie adb devices),
  • jeśli jest widoczne, wydajemy polecenie adb shell,
  • w powstałej konsoli wydajemy polecenie pm get-install-location – zapewne zobaczymy 0 lub 1, co oznacza odpowiednio wybór automatyczny lub wewnętrzną pamięć flash,
  • zmieniamy wartość na 2: pm set-install-location 2,
  • zamykamy konsolę adb, odpinamy telefon od komputera, wyłączamy USB debugging.

Przenoszenie programów na kartę SD

  • na telefonie wybieramy Ustawienia -> Aplikacje -> Na karcie SD,
  • „ptaszek” przy nazwie programu oznacza, że jest on na karcie SD,
  • wybieramy kolejno aplikacje i w ich ustawieniach wybieramy przenieś na kartę SD.

Po chwili powinniśmy zauważyć przyrost wolnego miejsca na wbudowanym w urządzenie nośniku.

Wady

Poza oczywistą zaletą, czyli możliwością instalacji większej ilości programów, co często oznacza być albo nie być dla urządzenia, są też wady:

  • wbudowana pamięć flash jest zwykle szybsza, niż karta, ale w praktyce nie odczuwam tego, na typowej lowendowej karcie,
  • niektóre aplikacje, zwł. systemowe lub Google nadal nie dają się przenieść,
  • przenoszone aplikacje zajmują nadal trochę miejsca na wewnętrznej pamięci.

Na zakończenie polecam lekturę pełniejszego opisu, z obrazkami (ang.) – widziałem kilka opisów, ale ten wydaje mi się najlepszy i najbardziej przystępny.

UPDATE

Debugowanie USB w Androidzie 4.2 i nowszych

W przypadku Androida w wersji 4.2 i nowszych, nie można tak zwyczajnie włączyć debugowania USB. Należy najpierw odblokować ukryte menu, a żeby to zrobić należy zostać programistą.
Wybieramy Ustawienia -> System -> Informacje o urządzeniu -> O telefonie i naciskamy 7 razy (nie, to nie jest żart). Po tym otrzymujemy informację, że zostaliśmy programistą. Następnie standardowo w Opcje programisty wybieramy Debugowanie USB.

Jak uruchomić komputer z USB, gdy BIOS nie ma opcji bootowanie z USB?

USB

Złącze USB przez Petr Kratochvil

Od paru lat komputery wyposażone są zwykle w opcję uruchamiania systemu z USB. Rozwiązanie znacznie lepsze, niż płyta CD: płyt jednorazowych trochę szkoda, żeby coś szybko przetestować, płyty wielorazowe się rysują, napędy CD-ROM mają długie czasy dostępu i są głośne. Dodatkowo, pod USB można podłączyć zwykły dysk twardy, albo mieć system RW na pendrive. Niestety, kiedyś bootowanie z USB było rzadkością, a nawet jeśli było, to urządzenie bywało widoczne nie jako zwykły dysk twardy, tylko USB-FDD. W każdym razie gdy ostatnio robiłem grzejnik, to najzupełniej prawidłowo przygotowany pendrive z grub’em, robiący za dysk twardy nie był widoczny jako urządzenie pozwalające na uruchomienie systemu.

 

Jak pisałem, znalazłem na to obejście: bootowanie z CD-ROM (który na szczęście zwykle jest obecny w starych sprzętach) pozwalające na dalsze bootowanie z USB. Rozwiązanie genialne w swojej prostocie, tylko jak to zrobić? Jest gotowiec w formie freeware (także dla firm): Plop Boot Manager. Narzędzie bardzo fajne, ale układ strony, sposób podziału pakietów i wreszcie dokumentacja jest poukładana IMHO fatalnie. Tzn. opisane jest wszystko, ale wygląda na bardziej skomplikowane, niż jest w rzeczywistości, część informacji powtarza się itp.

Tak naprawdę, aby przygotować płytę CD z bootloaderem należy pobrać z tej strony dwa narzędzia (plpcfgbt-0.11.zip oraz plpbt-createiso.zip), a następnie wykonać tylko 3 kroki:

  1. skonfigurować opcje bootowania przy pomocy plpcfgbt, tak by domyślnie bootował z USB. W przykładzie jest gotowiec: Hidden boot with usb: plpcfgbt stm=hidden cnt=on cntval=1 dbt=usb plpbt.bin
  2. przygotować obraz płyty przy pomocy skryptu create-iso.sh (tak naprawdę zwykłe mkisofs z odpowiednimi opcjami)
  3. nagrać obraz iso na płytę CD (ulubionym narzędziem)

Po włożeniu płyty do napędu, ustawieniu w BIOSie bootowania z CD-ROM i podłączeniu pendrive z systemem najpierw uruchomi się bootloader z CD-ROM, a następnie bootloader z urządzenia podłączonego do USB.

Powyższe dla Linuksa. Pod Windows też się da, z tego co widzę, bo autor daje wersje skryptów i programów pod oba systemy. Mam dziwne przeczucie, że pod Linuksem będzie łatwiej.

UPDATE: W ramach tematów powiązanych oraz linkowania się na krzyż, Franek opisuje po polsku nieco bardziej życiowe zagadnienie czyli, jak uruchamiać wiele liveCD z jednego USB.

 

Sierpień miesiącem rozkładu.

Zaczęło się niewinnie – karta dźwiękowa na USB (tani szajs za 5 zł) przestała nagle odtwarzać. Oglądałem sobie w najlepsze Filharmonię Dowcipu na YouTube

(jeden kawałek powyżej, warto poszukać innych, świetne aranżacje), ubolewając przy tym, że nie mamy w kraju takiego zespołu jak Loituma. Chodzi oczywiście o ich utwór Levan polka AKA leek spin AKA kręcenie porem.

Ogólnie lubię covery, zabawy z aranżacją i interpretacją, a Levan polka to tekst z lat 30, z którego – jak widać poniżej – można zrobić całkiem współczesnego hiciora:

I mam świadomość, że powyższy przypadek to raczej ewenement, jeśli chodzi o popularność, ale – mimo mojej nikłej wiedzy w temacie – jednak nie jest to jedyny tego typu przypadek (wystarczy poszukać wykonań utworu Herr Mannelig). Znaczy: coś robią ze starymi utworami. Tymczasem wczoraj w radio usłyszałem, że w polskich szkołach nie ma lekcji muzyki i że moooże wróci. Trochę się załamałem.

Koniec dygresji. W każdym razie surfowałem po YouTube i nagle cisza. Po włożeniu do huba lub portu USB karta zaświeci niemrawo diodą i umiera. Czyli raczej permanentnie jest skończona. Zastanawiam się czy to zwykły przypadek, czy po prostu godzina-dwie produkowania dźwięku na słuchawki nauszne to dla tego typu karty za duże wyzwanie. Wolałbym pierwszą opcję, bo jednak lubię posłuchać na słuchawkach czasem…

Kolejną rzeczą, która padła, jest RAM w moim starym komputerze. Wygląda, jakby przestał widzieć jedną kość. Ostatnio było podobnie (resety, błędy na memtest), ale wystarczyło tradycyjne wyjęcie kości, odkurzenie kompa i wszystko działało. Tym razem tak dobrze nie ma. Zrestartował się i od tej pory widzi 375 MB RAM (wg free -m). Przekładanie i przedmuchanie nie pomaga.

Co prawda komputer to stary grat (obudowa – więc IIRC także płyta główna – z 2000 roku), a kondensatory na płycie od lat wołają o pomstę do nieba (słynne czasy wadliwych, puchnących kondensatorów), ale włączam go tak rzadko i używam do tak prymitywnych zastosowań, że wymiana nie ma sensu.

Sama maszynka to piękny przykład, jak można rozbudowywać PC – zaczynał jako Duron 700 ze 128 MB RAM i Nvidią TNT2 i dyskiem 20 GB. Potem był upgrade RAM, następnie procesora do Athlon XP 2200+, dysku do 60 GB. Na koniec – z okazji sporej ilości gry w Counerstrike – upgrade grafiki do Radeona 9200. I gdzieś po drodze RAM do 512 MB. I powiem szczerze, że do niedawna chodził mi po głowie kolejny upgrade grafiki, żeby pograć czasem chwilę we współczesne FPSy, ale nic okazyjnego na AGP nie było. Tak, wiem, przydałoby się go wymienić. Ale w sumie do netu, posłuchania czy sczytania muzyki itp. wystarczy, a używam rzadko…

Skoro o sczytaniu muzyki mowa – zapowiadane sczytanie i cyfryzacja taśmy BKS nie odbyły się z powodu rozkładu instalacji audio. Konkretnie z powodu rozszabrowania większości kabli pod inne instalacje audio i zagubienia jednej przejściówki. Chciałbym, żeby limit rozkładu na ten rok był już wyczerpany.

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.

Sprawdzanie dysku USB w Debianie.

O tym, że warto monitorować stan dysku, nie trzeba – mam nadzieję – nikogo przekonywać. Wystarczy tylko dodać, że wczesne wykrycie anomalii może pozwolić na proste i bezpiecznie skopiowanie wszystkich danych. Jeśli ktoś nie chce lub nie czuje się na siłach we wnikanie w dobrze opisane na wiki parametry S.M.A.R.T, to jako wariant minimum proponuję przyjąć, że jakakolwiek różna od zera wartość dla Reallocated Sectors Count jest sygnałem, że warto szybko zrobić backup danych. A już na pewno warto spisać dysk na straty, jeśli ta wartość rośnie.

Jeśli chodzi o desktopy, to – jak podpowiada ike w komentarzu – dysk można sprawdzić korzystając z gsmartcontrol (zapewne dostępne w repozytorium pakietów dla Twojej dystrybucji). Na pewno wygodniejsze i łatwiejsze rozwiązanie.

Pisałem już o odczycie S.M.A.R.T w Debianie dla dysków w kieszeniach USB. W zasadzie temat wyglądał na wyczerpany, bo nowe smartmontools obsługują dyski w kieszeniach USB, ale… nie do końca. Niedawno miałem do czynienia z dwiema kieszeniami USB dla dysków 2,5″ – na jednej smartmontools nie umiało sprawdzić stanu dysku, na drugiej działało bez problemu.

Przeszedł bym nad tym do porządku dziennego, szczególnie, że żadna z kieszeni nie była moja, ale okazało się, że moja kieszeń 3,5″ też nie pozwala na sprawdzenie stanu dysku tak po prostu:

smartctl -a /dev/sdb
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sdb: Unsupported USB bridge [0x04b4:0x6830 (0x001)]
Smartctl: please specify device type with the -d option.

Zatem jak sprawdzić dysk w kieszeni USB? Okazało się, że opcji do -d w smartmontools jest nieco więcej. Ten wpis podsunął rozwiązanie problemu, jest nim dodanie parametru -d usbcypress. Czyli ostatecznie komenda to:

smartctl -a -d usbcypress /dev/sdb

Wynik lsusb dla mojej kieszeni USB:

Bus 001 Device 002: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI

Podobno dość popularny producent chipsetów. Dla wyczerpania tematu – chyba wszystkie sprzętowe kontrolery RAID (przynajmniej znane mi) również pozwalają na sprawdzanie S.M.A.R.T dla dysków SATA. Też warto sprawdzać, bo można dostrzec nadchodzący błąd wcześniej, niż zgłosi go kontroler…

Odczyt S.M.A.R.T. via USB w Debian Lenny.

Dyski potrafią się sypnąć – pewnie każdemu zdarzyło się odzyskiwać dane z dysku, który „umarł”. Dyski mechaniczne posiadają jednak bardzo przyjemną cechę, która może zapobiec utracie danych, czyli tytułowy S.M.A.R.T.. Tylko, że… nie działa w przypadku dysków podłączonych po USB. Przynajmniej w Debianie Lenny. Przynajmniej domyślnie.

Wikipedii przepisywać nie ma sensu, więc krótko: pod każdym systemem dostępny jest pakiet narzędzi smartmontools. Do niedawna pakiet obsługiwał dyski IDE, SCSI oraz SATA. Natomiast bezradny był w przypadku dysków podłączanych przez USB (przynajmniej pod Linuksem), co znacznie ograniczało jego skuteczność.

Byłem przekonany, że to kwestia protokołu, ale przy okazji rozmowy okazało się, że da się, co więcej, niektórze narzędzia pod Windows umieją to zrobić. Linux jak zwykle w tyle? Okazuje się, że niekoniecznie. Co prawda wersja z Debiana Lenny nie potrafi odczytać stanu dysku podłączonego po USB, ale wersja z testinga – jak najbardziej.

Pakiet jest dostępny w backportach, a dla tych, którzy wolą zrobić sami informacja – samodzielnie backportuje się trywialnie. Wystarczy dodać do /etc/apt/sources.list repozytoria ze źródłami dla testing, pobrać źródła smartmontools oraz libcap-ng w wersji dla testing (wajig source smartmontools; wajig source libcap-ng), przebudować na Lennym (dpkg-buildpackage) najpierw libcap-ng, zainstalować otrzymane libcap-ng0_0.6.2-4_i386.deb oraz libcap-ng-dev_0.6.2-4_i386.deb, następnie zbudować smartmontools. Tak naprawdę do działania potrzebne są tylko libcap-ng0_0.6.2-4_i386.deb oraz smartmontools_5.39.1+svn3060-1_i386.deb). I to wszystko. Od tej pory działa smartctl -A /dev/sda, gdzie sda to dysk w kieszeni USB.

Przydatna sprawa, zwłaszcza, że w nowym routerku dysk w kieszeni jest dość krytyczny – wszak wszystkie katalogi, które muszą być dostępne do zapisu są właśnie na nim…

PS. Podziękowania dla peceta za informację o tej zmianie w smartmontools.

Root tylko do odczytu (flash).

Trochę czasu minęło, odkąd pisałem o kluczu USB jako partycji root i tylko do odczytu. Oczywiście, jak się spodziewałem, nie wyczerpałem tematu i parę rzeczy wyszło w praniu.

Pierwsze – i w sumie najważniejsze – co wyszło – po przemontowaniu / w RW, instalacji nowych pakietów – nie daje się przemonotować w RO. Winnych było dwóch – blkid.tab oraz usunięte pliki nadal używane przez proces.

Szczęśliwie w trakcie poszukiwań rozwiązania wpadłem na ReadonlyRoot na Debian Wiki, gdzie opisane jest, co zrobić. W przypadku blkid.tab należy zrobić symlinka i ustawić zmienną środowiskową. W przypadku używania usuniętych plików – zrestartować odpowiednie serwisy (polecenie checkrestart z pakietu debian-goodies). Poza tym, skorzystałem z patentu na mtab.

Na koniec potwierdzenie pierwszego spostrzeżenia – jest stabilnie. Bez UPSa 14 dni było.