życie zabija powoli :)

syslinux troubleshooting oraz multi-live-usb

Nie tak dawno znalazlem w koncu sposob na zrobienie pozytku z pendrive 8gb kingstona.

Jest to model data traveller 101 II ( usb : 0951:1625 ), ktory wcale nie jest taki szybki jak by sie wydawalo. Jest to jeden z powolniejszych napedow, przynajmniej w zapisie. Odczyt jest na znośnym poziomie 4-7 MB/s.

Na urzadzenie wsadzilem rozmaite dystrybucje typu livecd, zintegrowalem sobie je w menu oparte na ukladzie i wyglądzie z crunchbang linux ( zainteresowani moga sobie przejrzec je tutaj ) i generalnie bylem zadowolony.

Pech chcial ze niechcacy sformatowalem je podczas testow w qemu. Niestety urzadzenie zostalo tam nazwane jako "QEMU VIRTUAL DISK", co mnie zmylilo i wybralem nieprawidlowy naped ;).

Po ponownym partycjonowaniu, reinstalacji syslinux i ponownym wrzuceniu dystrybucji okazalo sie ze z urzadzeniem dzieja sie dziwne rzeczy. Niektore komputery zglaszaja "Boot error", inne... zauwazaja pendrive'a dopiero przy startowaniu z dysku twardego (w tzw "boot menu" nie pojawia sie). Nawet lampka informująca o aktywnosci urządzenia migała ze sporym opóźnieniem od momentu włączenia komputera.

Po paru eksperymentach postanowilem sprobowac sformatowac urzadzenie z poziomu tinycore linux. Nie jestem pewien o co dokladnie chodzilo, ale pomógł albo format dysku tak zeby partycja wygladala jak fat16, albo wymazanie pierwszego 1mb urzadzenia przed instalacja MBR. I chodzi tu o standardowy format urzadzenia usb, bez wymuszania zgodnosci USB-ZIP.

Partycja montuje się jako FAT32, więc podejrzewam że jest tu jakiś trik mający na celu oszukać bios.

# fdisk -l /dev/sdc
(....)
Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
/dev/sdc1   *          62    15650907     7825423    6  FAT16

Po przeprowadzeniu tej operacji zapis na usb stał się zdecydowanie wolniejszy, ale problemy z uruchamianiem komputera z napędu usb zniknęły.

Tak wiec, jezeli ktos ma podobną zagwozdkę z syslinux - moze skrypt z tinycore rozwiąże problem? Przyczyna nie jest mi jeszcze dokładnie znana, może kiedyś odkryję o co dokładnie chodzi.

Lennart Poettering - współczesny standaryzator linuksa

Innymi słowy - bajeczka na dziś.

Tytułowa osoba może nie jest znana większości użytkowników, ale praktycznie każdy zetknął się z jego rozwiązaniami, o ile korzysta z aktualnych i popularnych dystrybucji.

Chodzi tu głównie o PulseAudio, które wciąż budzi mieszane opinie wśród użytkowników. Serwer dźwiękowy umożliwiający każdej aplikacji mieć własne ustawienia głośności i preferencji urządzeń audio, oraz możliwość przekazywania zdarzeń dźwiękowych na inny komputer/urządzenie poprzez protokół sieciowy.

Drugim projektem, nieco mniej znanym jest systemd, nowy system inicjalizacji dla dystrybucji linuksa, dostępny już w nadchodzącej fedorze 15. Z moich wstępnych testów na exherbo wynika że od wybrania systemu z listy w bootloaderze kernela do ujrzenia zapytania o login (w trybie tekstowym) mija około 10 sekund.

Innymi cechami systemd jest śledzenie działających usług przez initsystem i w razie czego wznawianie ich pracy, możliwość dokładnego profilowania oraz śledzenia drzewa zależności usług, możliwość korzystania z dbus do komunikacji z systemem, integracja z mnóstwem aktualnie wykorzystywanych technologii, a w przyszłości zastąpienie niektórych z nich (np consolekit, gdyż korzystanie z cgroups i automatyczne grupowanie usług i procesów przez systemd praktycznie robi to samo.

Można też wspomnieć o tym że definicje usług są dużo prostsze, a system uruchamiania nie korzysta z języków skryptowych, co ogranicza liczbę zbędnych procesów i zużycie pamięci - to czyni systemd atrakcyjnym dla rozwiązań zintegrowanych (embedded).

Ale to nie o PulseAudio ani bezpośrednio o systemd chciałem pisać. Chodzi o efekt uboczny prac przy systemd i jego integracji w Fedorze.

Podczas rozwoju tego initsystemu na jaw wyszło między innymi że usługi uruchamiane na starcie systemu trzymają tymczasowe dane w różnych miejscach, niekoniecznie do tego przeznaczonych, np. /var/run, /var/lib , /etc/, nawet /dev .

Czyli nie ma ogólnie przyjętego standardu na takie dane. Co więcej próba utrzymania systemd niezależnego od żadnej konkretnej dystrybucji wymagała mnóstwa adaptacji pod każdą konkretną dystrubucjię.

W związku z tym developer zaproponował wprowadzenie katalogu /run w systemie, gdzie udev, systemd i podobne usługi mogą trzymać swoje dane robocze. Chodzi tu o dane które z założenia nie mają przetrwać do kolejnego uruchomienia systemu. Mogą to być pliki socketów, pliki lock, dane robocze udev itp.

Oczywiście spowodowało to gwałtowną dyskusję, a wręcz kłótnie. Głównie odnośnie interpretacji standardu FHS określającego układ katalogów w systemie ( całą kłótnię widać tutaj ). Okazało się że reguł FHS nie naruszono, po prostu niektórzy mieli problemy z czytaniem ze zrozumieniem :].

Zmiana została przyjęta, ale nie była ostatnią. Idąc "za ciosem" developer systemd postanowił poprawić jeszcze kwestię ustawień które każda dystrybucja trzyma w innym miejscu. Chodzi głównie o takie ustawienia jak nazwa komputera, plik z wersją dystrybucji, miejsce zapisu ID komputera, ustawienia klawiatury itp.

Wszystko jest opisane tutaj i z tego co mi wiadomo, większość "dużych" dystrybucji już zgodziła się zaadoptować te zmiany u siebie.

Zmiany spowodują pewną unifikację podstawowej konfiguracji systemowej, co z kolei bardziej ustandaryzuje różne dystrybucje linuksowe.

Zastanawia mnie to, że do tej pory brak takiego ujednolicenia nie stanowił problemu. Może nikt go po prostu nie dostrzegał. Albo nikt nie podejmował się zadania napisania niskopoziomowego programu który poradziłby sobie na każdej dystrybucji linuksa.

Podsumowując, w systemie pojawił się nowy katalog zastępujący role kilku innych, a konfiguracja podstawowych parametrów systemu została bardziej ustandaryzowana.

Pare rzeczy jakich możesz nie wiedzieć o syslinux...

...bo nie są zbyt dobrze udokumentowane ;)

Syslinux jest bootloaderem, czyli programem który umożliwia uruchomienie systemu operacyjnego. Pozwala on na start z dysku/usb/dyskietki/sieci/cdrom, obsługuje różne systemy plików, ma wsparcie dla GPT, obsługę menu i różne inne fajerwerki ;)

Większość funkcji jest opisana, ale są dwie do których ciężko się dokopać, a mogą pomóc w niestandardowej konfiguracji lub systemie który ma problemy ze startem.

W katalogu gdzie zainstalowane są dane syslinux (na ogół /usr/share/syslinux lub /usr/lib/syslinux)
znajdują się moduły (pliki *.c32) oraz obrazy MBR.

Generalnie mamy tam mbr.bin, altmbr.bin oraz gptmbr.bin z wariantami _c oraz _f. Czyli generalnie 9 plików.

gptmbr.bin odpuścimy sobie - jest on używany przy stosowaniu partycjonowania GPT.

Najpierw mbr.bin - jest to standardowy MBR używany przez syslinux. Powoduje on wystartowanie z pierwszego dysku podanego przez BIOS i odszukanie partycji z flagą boot.

Wersja _c ma dodatkową funkcję która sprawia że podczas przytrzymania ctrl w trakcie startowania systemu syslinux ustawi dysk z którego startuje jako pierwszy dysk w systemie (gdy bios tego nie zrobił z jakiegoś powodu).

Wersja _f robi to samo, tylko że automatycznie.

altmbr.bin to MBR który ignoruje flagę boot na partycji i nie poszukuje takiej partycji w systemie. Zamiast tego wymaga podania mu numeru partycji, do której ma przejść podczas startu. Jest to przydatne przy współdzieleniu dysku z systemem windows.

Aby tego dokonać do pliku altmbr.bin należy dopisać jeden bajt z numerem partycji która ma zostać uruchomiona. Np

echo -ne "\x01" >> altmbr.bin 
cat altmbr.bin > /dev/sdc

Poprawny plik będzie mieć 440 bajtów.

Warianty _c i _f robią to samo co w przypadku mbr.bin.

Natomiast gdy wszystkie metody zawiodą, (a urzadzenie startuje spod kontrol qemu) pozostaje zmiana bootloadera. Są płyty główne gdzie syslinux nie działa, za to poprawnie startuje grub2.

uśpiona czujność w gentoo

Użytkownicy prelink, którzy niedawno instalowali glibc na ~x86 lub ~amd64 mogą mieć kompletnie padnięte systemy.

Okazuje się że glibc-2.13 nie lubi się z prelinkiem i uniemożliwia uruchomienie czegokolwiek. Rozwiązania są podane w https://bugs.gentoo.org/353814 .

Osobiście uważam to za niedopatrzenie osoby zajmującej się pakietem glibc. To, że glibc to pakiet sprawdzony i od lat uważany za stabilny (ostatnia wpadka tego pakietu to zmiana domyślnego formatu polskich dat parę lat temu, na miesiące w formacie rzymskim (wtf?)) nie znaczy że nie należy go weryfikować.

Co prawda gałąź ~arch oznacza "unstable", ale z kolei unstable nie powinno obejmować problemów postaci "cały system i wszystkie aplikacje nie uruchamiają się". To raczej błąd który powinien pojawiać się tylko w pakietach z kategorii "hard masked". A może się mylę?

Noworoczny prezent od developerów paludis/cave/exherbo.

Najnowsze, świeżo wydane, cave (paludis-0.56.2) dorobiło się (nareszcie) funkcji kasowania zbędnych źródeł z dysku. Do tej pory trzeba było używać hacka w pythonie o nazwie pclean.

Najnowsza wersja cave dodaje polecenie print-unused-distfiles, zwracające listę zbędnych źródeł w postaci prostej do przetworzenia. Nareszcie będzie porządek ;)

cave + eix - jak to zrobić?

Jak niektórzy wiedzą gentoo posiada narzędzie eix służące do szybkiego wyszukiwania pakietów w systemie.

Na ogół współpracuje on z standardowym managerem pakietów, czyli portage. Dla użytkowników paludis istnieje wtyczka która sprawia że po wykonaniu synchronizacji poprzez paludis następowało aktualizowanie cache'u eix na wszystkich repozytoriach używanych przez paludis.

Niedawno paludis został odstawiony na "boczny tor" przez developerów i obecnie rozwijany jest nowy klient, cave, nadal wchodzacy w sklad pakietu paludis.

Problem z cave polega na tym że dotychczasowa wtyczka dla eix przestała działać. W związku z tym przysiadłem i wyskrobałem nową, zgodną z nowym managerem.

/etc/paludis/hooks/sync_all_post

#!/bin/bash
[[ -x /usr/bin/update-eix ]] || return 0
source ${PALUDISEBUILDDIR}/echo_functions.bash
ebegin "Updating eix database"
opts=

for repo in $(${PALUDIS_COMMAND} --list-repositories | sed -n /^*/s/^..//p)

for repo in $(cave print-repositories)
do
[[ $(cave print-repository-metadata ${repo} | grep format | cut -d= -f 2) \
== "ebuild" ]] || \
[[ $(cave print-repository-metadata ${repo} | grep format | cut -d= -f 2) \
== "e" ]] || continue
location=$(cave print-repository-metadata ${repo} | grep \^location | cut -d= -f2)
opts="${opts} --add-overlay ${location}"
done

/usr/bin/eix-update -o ${ROOT}/var/cache/eix-tmp -q ${opts}

[ -f ${ROOT}/var/cache/eix ] && /usr/bin/eix-diff ${ROOT}/var/cache/eix ${ROOT}/var/cache/eix-tmp

/bin/mv ${ROOT}/var/cache/eix ${ROOT}/var/cache/eix.old

/bin/mv ${ROOT}/var/cache/eix-tmp ${ROOT}/var/cache/eix

dodatkowo musimy ustawić /etc/eixrc

OVERLAY_CACHE_METHOD="parse"

W przeciwnym razie eix będzie sypać błędami przy skanowaniu dodatkowych repozytoriów.

teraz wystarczy zrobić cave sync i sprawdzić czy pakiety z repozytoriów pokazują się w eix.

epic recovery

Mialem kiedys w firmie na kompie windows xp, którego i tak nie używałem.

Traf chcial ze padl mi dysk, więc przesiadłem się na zapasowy jaki ostal mi sie z poprzedniego komputera (mozna bylo sobie zatrzymac przy wymianie sprzętu). Niestety w międzyczasie zdążyłem go "zaorać" i nie miałem na nim żadnego systemu.

Nie miałem czasu aby zawracać gitarę działowi technicznemu i w 20 minut postawiłem sobie arch linux i zapomniałem o problemie - do pracy na helpdesku jak na razie mi wystarczał. Instalacja windows wymagała by zapewne oddania komputera na kilka godzin i postoje w pracy. A byłem akurat pod presją czasu.

Niestety czasy się zmieniają i będę musiał korzystać z jakiegoś nowego softu na jedyny słuszny system do współpracy z słuchawkami USB, model Plantronics Blackwire C210-M. Co prawda udało mi się je skonfigurować za pomocą snd-usb-audio, ale odpalanie softu do odbierania połączeń telefonicznych przez wine jednak do mnie nie przemawia.

Postanowiłem odzyskać instalację windows, aby nie zawracać gitary technicznym (logowanie do AD i rozmaita konfiguracja), administracji (zdobycie płytek instalacyjnych) i tracić więcej czasu niż to konieczne. Dysk uparcie odmawiał współpracy z komputerem firmowym, wydawał różne dziwne dźwięki i generalnie spowalniał działanie systemu. Zabrałem go do domu, gdzie .... zadziałał bez problemu. Jedynym problemem był jednostajny, miarowy pisk wydobywający się z urządzenia (na tyle uciążliwy że powodował ból głowy po kilku minutach.

Jako że jedynym pojemnym nośnikiem jaki miałem pod ręką w tym momencie był pendrive 8GB, spakowałem partycję windows za pomocą tar. Zwykłego tar'a. Pominąłem tylko plik wymiany.

tar cjf windows.tar.bz2 /mnt/win --exclude=pagefile.sys

Dostałem spakowany system w rozmiarze ~3GB.

W pracy zrobiłem partycję ntfs i wypakowałem plik. Niestety grub nie potrafił jej wystartować. Okazało się że mkfs.ntfs niezbyt poprawnie zakłada partycje ntfs. Pewnie zabrakło RTFM z mojej strony.

Wystartowałem plytę instalacyjną xp i skasowałem oraz ponownie utworzyłem partycję (instalator twierdził że wytwór mkfs.ntfs jest błędny) . Btw, jeżeli jesteście ciekawi kiedy instalator xp instaluje MBR na dysku twardym - zaraz po formacie partycji lub tuż przed nim. Ponieważ interesowało mnie tylko utworzenie partycji + format, straciłem dostęp do swojego systemu. Musiałem ratować swój bootloader za pomocą wcześniej przygotowanego liveusb.

Ponownie rozpakowałem archiwum z usb na partycję ntfs, tym razem już poprawnie utworzoną. Podpiąłem wpis z xp do grub'a. Poprawiłem windowsowe boot.ini, bo rozpakowałem go na drugą partycję, a wcześniej był na pierwszej (numer partycji w boot.ini z 1 na 2).

Wystartowałem.

Zobaczyłem typowe logo ładowania xp. A po dwóch sekundach pokazał mi się ekran logowania do systemu. Zdębiałem. Zalogowałem się do domeny, posprawdzałem czy wszystko działa. Działa i to bez problemu.

Poinstalowałem aktualizacje, skasowałem stare programy. Wszystko działa szybko i zgrabnie. Nawet więcej - na sprzęcie z 2004 roku aż zbyt zgrabnie. Płyta windows xp zoptymalizowana za pomocą nLite nie działa tak szybko.

Czyli - spakowałem system bez patrzenia na uprawnienia czy jakieś atrybuty, do pliku tar.bz2 i rozpakowałem na inną partycję NTFS, zamontowaną pod linuksem. I nic więcej nie musiałem robić aby odtworzyć windows xp z takiej kopii. A w grę wchodził obraz partycji za pomocą dd.

Wnioski

1. 
   
2. tar nadaje się do robienia backupów nie tylko systemów linuksowych
   
3. położenie NTLDR na partycji NTFS jest najwidoczniej bez znaczenia (przy rozpakowywaniu wylądował prawdopodobnie gdzieś na środku partycji)
   
4. domyślnie sformatowana partycja NTFS ma ustawiony własny sektor startowy
   
5. tar to bardzo skuteczne narzędzie do defragmentacji partycji windows ;)
   
6. instalator windows to narzędzie diabła - nadpisanie MBR następuje na samym początku instalacji, a chyba powinno na końcu. Gdy w połowie instalacji nośnik instalacyjny okaże się uszkodzony a MBR jest już nadpisany - problem
   
7. mój domowy komputer jest magiczny - już drugi uszkodzony dysk sata zadziałał na nim bez problemów i udało się odzyskać dane ;)
   

Dodatkowy wniosek - obraz partycji to nie jedyna skuteczna metoda backupu systemu windows. A przywrócenie systemu nie wymaga specjalnych tricków z MBR lub kopiowania wybranych specjalnych sektorów dysku. Spakować, utworzyć partycję, rozpakować.

Jak widać w typowym przypadku jest to wystarczające. Podejrzewam że w przypadku stosowania szyfrowanych lub kompresowanych katalogów trzeba by jednak skorzystać z obrazu partycji.

No cóż, a teraz muszę szykować się do przejścia na windows w pracy.

eksport wybranego commita z git do zip/tar.gz

Od jakiegos czasu mam firmowy svn zaciagniety do git, za pomoca git-svn. Dziala to sprawnie i szybko, bije na leb jakakolwiek przegladarke svn i jest odporne na problemy sieciowe. A dzieki cgit mam bardzo wygodne mozliwosci ogladania zmian.

Problemem jest wyeksportowanie wybranego commita do pliku zip. Tak aby zawieral pliki w wybranej wersji tylko z danego commita. Cgit pozwala tylko wyeksportowac caly branch w danej wersji do archwium. Tak wiec sadzilem ze operacja jakiej ja potrzebowalem nie jest mozliwa do wykonania.

A jednak, po dlubaniu w dokumentacji okazalo sie to mozliwe. Wchodzimy do cgit i szukamy interesujacego nas commita. Zalozmy ze jest on oznaczony 1234.

Wchodzimy do katalogu z git'owym klonem svn'a (lub zwyklego repozytorium git) i wykonujemy polecenie

git archive -o ~/1234.zip 1234 `git show --pretty="format:" --name-only 1234`

W efekcie dostajemy plik zip zawierajacy pliki ktore zostaly dodane/zmienione w commicie 1234. I nie jest to diff, ale archiwum zawierajace kompletne pliki. Czyli to co mnie interesowalo.

cache'owanie dns za pomocą dnrd

Reogranizacia sieci w pracy spowodowala ze tragicznie działa mi DNS. Czasami na odpowiedź trzeba czekać parę sekund. Co jest bardzo dziwne, bo kiedys łączyliśmy się z drugim końcem miasta, a teraz wszystko jest w jednym budynku ;]

O ile nie ma to dużego znaczenia przy korzystaniu z przeglądarki i zdalnych terminali, to potrafi dać się we znaki przy korzystaniu z git-svn lub innych aplikacji często odpytujących serwer dns (zdarzało się że klient jabber miał z tym problemy).

W ramach eksperymentu zainstalowałem sobie na komputerze dnrd. Jest to właśnie to co w opisie - daemon których cache'uje zapytania dns.

Konfiguracja jest prosta. Po pierwsze sprawdzamy jakie mamy serwery dns. Na ogół wystarczy spojrzeć do /etc/resolv.conf.

Podmieniamy /etc/resolv.conf aby był tam tylko jeden wpis

nameserwer 127.0.0.1

Teraz dla pewności pingujemy jakiś serwer/otwieramy jakąś stronę w przeglądarce, powinno się nie udać ;)

Teraz uruchamiamy jako root polecenie

dnrd -s dns1 -s dns2 -d4

oczywiście podmieniając dns1, dns2 na adresy ip serwerów dns jakie mieliśmy do tej pory w /etc/resolv.conf. Każdy adres ip serwera dns poprzedzmay przez -s w linii poleceń dnrd.

To wywołanie uruchomi dnrd bez przechodzenia w tło z mnóstwem info diagnostycznego. Jeżeli komputer wyśle jakiekolwiek zapytanie do dns to tutaj się na pewno pojawi.

Zostawiamy włączony dnrd i pingujemy wybrany serwer (co najmniej kilka razy) lub próbujemy coś otworzyć z poziomu przeglądarki i sprawdzamy czy odpytywanie DNS działa i co robi dnrd. Jeżeli widzimy szybszą pracę zapytań DNS, możemy skonfigurować sobie dnrd na stałe.

W przypadku dystrybucji Arch linux trzeba zrobić następujące modyfikacje (w przypadku korzystania z dhcpcd)

/etc/conf.d/dhcpcd

DHCPCD_ARGS="-q -C 20-resolv.conf "

/etc/rc.local

dnrd -s pierwszy_dns -s drugi_dns -l

(Parametr -l powoduje logowanie aktywności do syslogu, nie jest ono aż tak obszerne jak w przypadku -d4).

/etc/resolv.conf.head

nameserver 127.0.0.1

Po restarcie sprawdzamy plik /etc/resolv.conf pod kątem wpisu z 127.0.0.1 oraz czy dnrd pracuje. I to w sumie wszystko.

W moim przypadku poprawa jest bardzo widoczna przy synchronizacji lokalnej kopii svn za pomocą git svn. Poprawa prędkości jest mniej więcej trzykrotna.

Wacom Bamboo Tablet i xorg - konfiguracja po nowemu i staremu

Niedawno zaopatrzyłem się w tablet Wacom Bamboo. Model CTL-460, działa tylko z dołączonym piórem i nie ma dodatkowych przycisków. Dla mnie jak znalazł.

Dylemat zaczął się przy konfiguracji tego urządzenia. Na gentoo sterownik linuxwacom chcial downgrade'owac mi xorg-server do 1.6.5 bodajże. Nie ma mowy ;).

Zajrzałem do Archa. W AUR jest taka oto paczka : linuxwacom-bamboo-cth-ctl. Po skompilowaniu dostajemy aktualny moduł do jądra (wacom.ko), narzędzia dla X, konfigurację udev i HAL oraz sterownik xf86-input-wacom.

Autokonfiguracja z wykorzystaniem HAL
Konfiguracja jest prawie dobra, dla korzystających ze starszego X servera (<=1.7.x) gdzie autokonfiguracja oparta jest jeszcze o HAL. Wymagane poprawki to
/etc/udev/rules.d/10-wacom.rules dla udev :
KERNEL=="event*", ID_VENDOR_ID=="056a", NAME="input/%k", SYMLINK="input/wacom"

oraz /usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi dla HAL : klik

Po instalacji wystarczy wyjsc na chwile z X i uruchomic
udevadm trigger.

Uwaga: Nie radzę tego robić przy działających X'ach. Zgasł mi ekran, przestała działać klawiatura i w ciemno musiałem resetować ;)

Powinnismy dostac urzadzenie /dev/input/wacom (i pare innych). I w sumie tyle. Wystarczy uruchomic srodowisko graficzne i tablet zacznie dzialac.

Xserver 1.8.0 i udev
Jako że HAL odchodzi do lamusa xorg-server-1.8.0 oferuje nowy sposób (auto)konfiguracji oparty bezpośrednio na udev. Zmiany wymagają regułki hal'a, na prostsze.

Najpierw musimy podpiąć tablet i uruchomić X'y. Następnie zaglądamy do /var/log/Xorg.0.log i szukamy linii podobnej do tej :
(II) XINPUT: Adding extended input device "Wacom Bamboo 4x5 Finger"


Interesuje nas nazwa urządzenia z tej linii. Teraz możemy utworzyć regułki X :

/etc/X11/xorg.conf.d/10-wacom.conf

Section "InputClass"
Identifier "Wacom Tablet"
MatchProduct "Bamboo 4x5 Finger"
MatchDevicePath "/dev/input/event*"
Driver "wacom"
EndSection

i w sumie tyle. Restart X i po problemie.

Jak to zrobić na gentoo?

Moja metoda polegała na zainstalowaniu sobie pacmana (managera pakietów archlinux). Jest dostępny w moim nieoficjalnym overlay http://github.com/yoshi314/yoshi314-overlay

Aby skompilować należy
- ściągnąć pliki z http://aur.archlinux.org/packages.php?ID=31540 (link "Archive")
- rozpakować do osobnego katalogu
- z poziomu zwykłego usera puścić polecenie
makepkg -d
co powinno pomyślnie skompilować nam cały sterownik.

W katalogu powinien powstać plik linuxwacom-bamboo-cth-ctl-20100412-1-i686.pkg.tar.gz lub podobnie nazwany.

Teraz:
- Rozpakowujemy go do swojego systemu, poprawiamy konfigurację hal i udev jak opisano wyżej.
- Plik /usr/share/linuxwacom/wacom.ko wrzucamy do katalogu modułów swojego kernela, zastępując dotychczasowy sterownik wacom.ko, lub jeśli nie mamy takiego (bo nie kompilowaliśmy) wrzucamy plik do
/lib/modules//kernel/drivers/input/tablet/wacom.ko gdzie wersję kernela można ustalić poprzez wykonanie "uname -r"
- Wyłączamy X
- odpinamy tablet
- usuwamy moduł wacom z pamięci (jeżeli mamy załadowany)
- depmod -a
- ładujemy moduł wacom
- startujemy X'y

I to chyba wszystko. Zaawansowana konfiguracja - to już temat na inny wpis (sam nie miałem potrzeby jej stosować do tej pory). Wytrwali mogą zrobić sobie ebuild ;)

Uwaga:Ręczna rekompilacja paczki linuxwacom-bamboo-cth-ctl wymaga następujących kroków
- kasujemy katalog pkg
- kasujemy katalog src (tak, naprawdę)
puszczamy makepkg -d --force
- powtarzamy procedurę instalacji