Kategoria: Linux

Opublikowane w

3 rzeczy w Debianie, których nie aktualizujesz.

Jeśli korzystasz z systemu Debian, to zapewne przywykłeś do wygodnej sytuacji, że aktualizacje zwykle przychodzą w repozytorium security. Jest to wygodne, bo proste apt-get update; apt-get upgrade teoretycznie zapewnia aktualne wersje wszystkich pakietów w systemie, z aktualizacjami bezpieczeństwa. Prawda?

Niestety, nie do końca. Po pierwsze, sama instalacja aktualnych wersji pakietów nie zawsze oznacza, że automatycznie zaczynają być one używane. Pomijając kernel, którego faktyczna aktualizacja wiąże się z rebootem, także inne programy niekoniecznie zaczynają być używane automatycznie w aktualnej wersji po ich instalacji. W określeniu programów do restartu przydatne bywa polecenie checkrestart z pakietu debian-goodies, o którym pisałem w ściągawce z przydatnymi poleceniami dla Linuksa. Ogólnie: próbuje ono podać procesy, których restart jest wymagany ze względu np. na aktualizację bibliotek.

Ale i to nie wszystko. Jest kilka innych rzeczy, które nie aktualizują się, mimo zainstalowanych paczek, które spowodowały ich obecność w systemie:

  1. Flash od Adobe. Popularny na desktopach, spaczkowany – w specyficzny sposób – w Debianie w pakiecie flashplugin-nonfree, przy okazji podobno popularny wektor ataku. Aktualność swojej wersji Flasha można sprawdzić na stronie Flash Player check. Jakoś wolę ten sposób od strony Adobe. Aby zaktualizować wersję w systemie należy wydać polecenie: 
    update-flashplugin-nonfree --install --verbose

    Oczywiście po powyższym trzeba zrestartować przeglądarki, żeby zmiana była efektywna.

  2. Java od Sun. Ze względu na zmianę polityki, niedawno Java od Sun przestała być aktualizowana, również w zakresie aktualizacji bezpieczeństwa w Debianie i Ubuntu. Jeśli nadal korzystasz z niej w systemie, jest spora szansa, że masz starą wersję, o której aktualizację musisz zadbać samodzielnie. Można też zmienić wersję na którąś z wolnych alternatyw.
  3. Mikrokod procesora. Jeśli posiadasz procesor Intela, to dostępne są aktualizacje mikrokodu od producenta. Co prawda bez tego też będzie działać, ale może udało się poprawić coś, co zwiększy wydajność? Sama instalacja pakietu microcode.ctlnie wystarczy, by zawsze mieć aktualną wersję zainstalowaną i wykorzystywaną w systemie. Aktualizację obecnego w systemie mikrokodu można wywołać ręcznie poprzez polecenie: 
    update-intel-microcode

    Potem można przeładować mikrokod przy pomocy:

    /etc/init.d/microcode.ctl restart

    Począwszy od wersji Wheezy niestety jest to nieco bardziej skomplikowane i aktualizację mikrokodu w Debianie opisałem w osobnym wpisie.

Powyższe aktualne dla Debiana (głównie na desktopie, stąd nic o bazach wirusów, filtrach antyspamowych itp.), zapewne także dla pochodnych typu Ubuntu. Chyba, że tam jest to lepiej rozwiązane?

UPDATE: Przeładować owszem, można, ale jeśli dokonywana jest aktualizacja, to przeładowanie jest automatyczne.

UPDATE: Wzmianka o nowym sposobie aktualizacji mikrokodu we Wheezy.

Opublikowane w

Klawisze regulujące jasność Linux – rozwiązanie problemu.

Jakiś czas temu pisałem o laptopie Fujitsu-Siemens Esprimo V6515, którego opisywałem prawie dwa lata temu. Okazało się, że da się uruchomić należycie działającą regulację jasności. I prawdopodobnie dało się już wtedy, ale sposób jest mocno nieoczywisty. Ponieważ znalezienie rozwiązania zajęło mi dłuższą chwilę, obejmowało zabawy z debugiem ACPI itp. frajdy (zanim zadałem właściwe pytanie do wyszukiwarki), to zamieszczam.

Ogólnie problem był taki, że wciśnięcie klawisza brightness up powodowało wysłanie zarówno zdarzenia ACPI brightness up, jak i – natychmiast po nim brightness down. Przy czym sam brightness down działał normalnie. Rozwiązanie (warto wypróbować, jeśli ktoś ma problem z działaniem klawiszy do zwiększania jasności w laptopie) to dodanie opcji brightness_switch_enabled=0 do modułu kernela video. Najprościej trwale:

echo "options video brightness_switch_enabled=0" > /etc/modprobe.d/video.conf

Źródło: Brightness up/down key sensibility.

Opublikowane w

Praca na desktopie z małą ilością RAM po raz trzeci – zram.

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi „newsa” o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta – swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później – tradycyjnie – na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci na swap!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne – zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

  • cat /sys/block/zram0/compr_data_size – rozmiar danych po kompresji
  • cat /sys/block/zram0/orig_data_size – rozmiar nieskompresowanych danych
  • cat /sys/block/zram0/mem_used_total – całkowita ilość zużytej pamięci
  • swapon -s – rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem…) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK – zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram – więcej przykładów w linku do wiki Gentoo.