Dzisiaj dzień pod znakiem instalacji Linuksa na laptopie Toshiba Satellite 2060CDS. Stary to laptop, bo w środku posiada jeszcze takie zabytki jak:

  • 366 MHz AMD K6-2
  • 96 MB SDRAM
  • 4 GB HDD
  • 12.1" 800x600 LCD

Chciałem sobie ułatwić trochę życie wrzucając na niego VidaLinux i potem przerobić go na Gentoo, jako, że Vida jest dystrybucją opartą o system z rybą w logo :) Niestety jak już przebrnąłem przez instalację to okazało się, że Vida jest kompilowana pod procesory i686 i próba uruchomienia chociażby Bash'a kończyła się komunikatem "Illegal instruction" (AMD K6 należy do rodziny procesorów i586). No i musiałem odpalać jakieś livecd i robić wszystko na chroot-cie korzystając ze stage3.
Innym problemem jest to, że wiatrak w laptopie nie chce się kręcić (pod windą działa - pewnie kwestia dokonfigurowania ACPI) przez co musiałem tymczasowo dokleić zewnętrzny wiatraczek do obudowy, bo się maszyna sama wyłączała przy większym obciążeniu.

Kurde, ile krwi potrafi zepsuć jedna, mała pierdółka. Przez źle wpisaną flagę CFLAGS straciłem pół nocy na dociekanie czemu większość programów nie chce się skompilować. Problemem okazał się cholerny znak końca linii (Enter), który wcisnął się tam gdzie nie powinien.
Było:

CFLAGS="-march-k6-2 -mcpu=k6-2 -s -Os -pipe -fomit-frame-pointer
-mmmx -m3dnow"

A powinno być:

CFLAGS="-march-k6-2 -mcpu=k6-2 -s -Os -pipe -fomit-frame-pointer -mmmx -m3dnow"
Dobrze, że w końcu odkryłem ten problem, bo już zaczęły mi przelatywać przez głowę myśli o wyrzuceniu tego złoma przez okno. Niestety, to nie był jedyny problem. Do tej pory nie udało mi się uruchomić karty sieciowej na PCMCIA Xircom REM-56G. Google mówi, że to czy ona zadziała pod Linuksem to właściwie kwestia przypadku. Jednym działa, innym nie. Już nawet pokusiłem się o upgrade firmware'u na tej karcie, co jednak nie przyniosło żadnych widocznych skutków. Można powiedzieć, że działa połowicznie: przy pingowaniu wysyła pakiety w sieć, ale odebrać ich już nie potrafi.
No cóż, skoro nie działa Ethernet to może by tak uruchomić sieć po WiFi? No dobra, już wiem, że mam kartę WLAN USB na chipsecie Prism2.5 i potrzebuję do tego pakietu linux-wlan-ng. Emerguję (od polecenia emerge) linux-wlan-ng-0.2.1-pre20, pięknie się kompiluje, ale gdy próbuję załadować prism2_usb to dmesg wyrzuca "unknown symbol". Miodzio. Co jest do cholery?? Przecież na moim dużym kompie to działa! Czyżby chłopcy od kernela zdążyli coś zmajstrować od wersji 2.6.11...? (na laptopie jest już 2.6.12). Zainstaluję coś nowszego... patrzę do portage'a, a tam najnowsza wersja wlan-ng to 0.2.1-pre23... eh, najnowsza wersja na stronie to 0.2.1-pre26 z datą 25 stycznia 2005 i do tej pory nie znalazła się w portage'u... Szybcy są... :(
W końcu udało mi się odpalić tego WLAN-a używając wersji pre26 :)

UPDATED:
Coś jest nie tak z tym laptopem. Już 3 razy zaliczył "kernel panic" i to na róznych jądrach; z magicznych informacji, które wypisał przy tej okazji wynika, że to ma coś wspólnego z pamięcią wymiany. Jednak skanowanie dysku pod kątem błędnych bloków niczego nie wykazało.
Upgradowałem mu BIOS: z wersji 7.00 do 7.80 - niestety nie znalazłem żadnej listy zmian, więc nie wiem co wnosi dobrego ta aktualizacja (notabene, ta Toshiba ma najuboższy bios jaki widziałem).
Gdyby ktoś potrzebował to zamieściłem ten BIOS pod adresem: http://zibik.homelinux.org/downloads/1206cv78.exe (musiałem zarejestrować się na driverguide.com, żeby go dostać, brrrr)

UPDATED 2:
Nie wiem czy pomogła aktualizacja biosu, czy coś innego ale jak na razie działa stabilnie. W międzyczasie skompilowałem mu jajko 2.6.11 i karta sieciowa sieciowa (ten nieszczęsny Xircom) zaczęła działać. Wniosek z tego taki, że lepiej używać 2.6.11.12 niż 2.6.12.2.
Tylko to cholerne distcc nie chce teraz działać, przez co kompilacja GCC trwała ponad 12 godzin :(
Ciekaw jestem jak bardzo skompilowanie GLIBC z obsługą NPTL wpłynie na wydajność systemu....

UPDATED 3:
W międzyczasie zrobiłem test i skompilowałem GLIBC na jednym z moich "dużych" komputerów. Chciałem sprawdzić czy system będzie działał na glibc z NPTL bez obsługi linuxthreads. O dziwo, wszystko poszło bezboleśnie - spodziewałem się, że coś "wykrzaczy", a tymczasem cały system działa bez problemu. Teraz widzę, że nie było dobrym pomysłem kompilować na laptopie GLIBC zarówno z obsługą NPTL jak i linuxthreads - czas kompilacji w takim przypadku wydłuża się dwukrotnie, ponieważ najpierw jest kompilowane glibc z obsługą linuxthreads, a potem drugi raz z obsługą NPTL.
Dobrą sprawą jest również użycie flagi "userlocales". O ile dobrze wiem, powoduje ona kompilowanie lokalizacji glibc-a zdefiniowanych w /etc/locales.build, a nie wszystkich dostępnych (po co mi np. obsługa japońskiego czy chorwackiego w systemie?) Plik locales.build u mnie wygląda tak:
en_US/ISO-8859-1
en_US.UTF-8/UTF-8
pl_PL/ISO-8859-2
pl_PL.UTF-8/UTF-8

A całe polecenie do instalacji glibc tak:

USE="nptl nptlonly pic userlocales" emerge -va glibc