No cóż, jestem blondynką ze wszystkimi konsekwencjami tego. Dnia 8.09.2010 zaplanowałam sobie kompilację jajka. Więc 7 cały dzień (no prawie) ciągłam z kernel.org source najnowszego stabilnego jajka. 9 przystąpiłam do kompilacji, czytając wcześniej sporo na ten temat. Idąc za radą jednego z bardziej doświadczonych kolegów (na forach też pisało podobnie) zaimportowałam .config z poprzedniego jaja. No i podołączałam, to co trzeba (reszty nie ruszając, to była moja dziewicza kompilacja przecież). Skąd wiedziałam co trzeba? Ano miałam takie źródła:

  • - programik hardinfo (system information) i wygenerowany przez niego raport w html’u
  • - wyniki ze strony http://kmuto.jp/debian/hcl/ po wklejeniu wyniku polecenia # lspci -n
  • - wyniki komendy lspci -k >sprzęt
  • - wyniki komendy lsmod >moduły

No i make xconfig. Pluł się że nie mam qt, więc zainstalowałam, korzystając z synaptica. Dlaczego? Ponieważ nie chciałam już się wgłębiać jakie pakiety są mi potrzebne. ctrl+f i jazda.
Po instalacji komenda już działała prawidłowo. To co zobaczyłam trochę mnie zdziwiło. To na prawdę mogę zdecydować co mój system będzie obsługiwał i jak będzie działał? Hmm, ale co oznaczają te wszystkie wpisy?
I tak ktoś z tytułem Technika Informatyka dowiaduje się, że na temat własnego sprzętu wie relatywnie niewiele. Zaznaczyłam tyko to, co mi wyszło z wyników powyżej, nie zmieniając nic poza tym (no przecież config powinien dziaałać).
No to zabieram się za kompilację. Jako że bezpieczniej było zrobić to debian-way (mam debian lenny, mam w zasadzie używać jedynie stable, bo jestem początkująca, wolę by ktoś wcześniej miał podobne problemy), wydałam w terminalu komendę

fakeroot make-kpkg –initrd –append-to-version=-piatkosia kernel_image kernel_headers

No i poczekałam sporo czasu. I zonk. Skubaniec wypluwał coś takiego na konsolę.
====== making target debian/stamp/install/linux-image-2.6.35.4 [new prereqs: ]======
This is kernel package version 11.015.
echo „The UTS Release version in include/linux/version.h”; echo „       „” „; echo „does not match current version:”; echo „       „2.6.35.4″ „; echo „Please correct this.”; exit 2
The UTS Release version in include/linux/version.h
       „”
does not match current version:
       „2.6.35.4″
Please correct this.
make[1]: *** [debian/stamp/install/linux-image-2.6.35.4] Błąd 2
make[1]: Opuszczenie katalogu `/home/piatkosia/Desktop/jajo/linux-2.6.35.4′
make: *** [linux-image] Błąd 2

No ładnie. Pewnie coś popsułam. Zastanawiałam się tylko co. Próbowałam jeszcze raz kompilować, zmieniać ustawienia, przenosić źródła do /usr/src, co ja jeszcze kombinowałam. No dobra, po 6 kompilacji odpóściłam. Byłam offline, znikąd pomocy, przecież ludzi nie będę budzić. Kogo nie pytałam, dawał mi standardową odpowiedź admina nr 1 (przypomnę: „U mnie działa”), albo proponował mi przejście na windows (którego z resztą również używam, jako że chcę wyrobić w sobie niezależność od platformy systemowej).

Nadszedł 9.09. Postanowiłam zapytać na kanale. (Czemu nie zapytałam wyszukiwarki? Chodzi o jakieś nawiązanie kontaktu. Tak to jest chwilę o czym mówić, i ktoś poczuje się chwilę potrzebny. Sama lubię pomagać innym jak coś wiem. Następnie zajrzałam do google. Po przeleceniu x tematów okazało się, że wina nie leży w błędzie kompilacji, a w pakiecie kernel-package, konkretnie w jego wersji 11.015. Znalazłam w sieci patch na ten problem.
No to zassałam http://ubuntuforums.org/attachment.php?attachmentid=150800&d=1269121765 ten pliczek i zrobiłam to co napisali.
apt-cache policy kernel-package
cd /usr/share/kernel-package
 sudo cp -v ruleset/misc/version_vars.mk{,.orig}
sudo cp -v ruleset/targets/common.mk{,.orig}
patch -p1 -i /home/piatkosia/Desktop/kernel-package-11.015-2.6.34.patch.txt
No i ten sam błąd. Jak na złość.
Nic, tylko weszłam na debian org i skorzystalam z wyszukiwarki pakietów i pobrałam wersję dla sida chyba czy squeze (or sth). Link bezpośredni do pakietu poniżej:
http://ftp.pl.debian.org/debian/pool/main/k/kernel-package/kernel-package_12.036_all.deb

To rozwiązało powyższy problem i miałam już upragnione pliki deb z kernelem oraz headersami. Na virtualnej działały, odbębniłam więc zwycięstwo, nie będąc świadomą, że zabawa dopiero się zaczyna, a jej wynik będzie dopiero za 2 dni.
No to jak działa, heja $su
hasło: (nie było tu nic widać)
ścieżka# dpkg -i *.deb
Nie chciało mi się pisać nazw. Miałam tylko 2 debpaczki w folderze, więc to w zupełności wystarczyło.
Paczki się zaistalowały, reboot, kernel panic.
No jasne, to było do przewidzenia. No ale kto powiedział, że tak szybko uda mi się to prawidłowo zrobić? Ale się nie poddam. Kartka, długopis, zapisałam to co wypluwał kochany dmesg. Jako że nie lubię obrazków przy ładowaniu, nie mam nigdy żadnego splasha przy bootowaniu.
Brzmiało to mniej więcej tak „Unable to mount root fs on unknown-block(0,0)” i miało związek (jak przeczytałam) z błędami w bootloaderze.
Patrząc na wpisy w /boot/grub/menu.lst (bo mnie straszyli że grub2 jest ciężki w konfiguracji, wybieram 1 przy instalacji) zobaczyłam, że w linijce z nowym kernelem (konkretnie w 2 linijkach, bo 1 na single)
nie ma wpisu o initrd. No to kaplica. Nie mam sieci, czekam do jutra. Nadszedł już 10 dzień.
Wbiłam ja w sieć, w celu poszukiwania wszelkich informacji o tym. Przy okazji dowiedziałam się co to jest i do czego służy. To coś działa w ramie, zwiększając użyteczność jaja, dołączając do niego moduły i takie tam. Pełno info w sieci na ten temat. Nie będę się rozpisywać. Znalazłam w końcu komendę, która mi go wygeneruje.
 mkinitrd -o /boot/initrd.img-2.6.35.4
Ojć… bash: mkinitrd: command not found
No tak. Ładnie
No ale nieustraszona linux-userka wykonuje komendę as root
apt-get install mkinitrd

no i co widzę?
Czytanie list pakietów… Gotowe
Budowanie drzewa zależności       
Odczyt informacji o stanie… Gotowe
E: Nie udało się odnaleźć pakietu mkinitrd

Faaajnie, zajebioza. Już traciłam nadzieję, ale odruchowo wykonałam mk[tab][tab]
efekt:
mkbimage          mkfs.cramfs       mkinitramfs-kpkg  mkswap
mkboot            mkfs.ext2         mkisofs           mktemp
mk-build-deps     mkfs.ext3         mklost+found      mktexfmt
mkdir             mkfs.ext4         mkmanifest        mktexlsr
mke2fs            mkfs.ext4dev      mk_modmap         mktexmf
mkfifo            mkfs.minix        mknod             mktexpk
mkfontdir         mkgraticule.py    mkocp             mktextfm
mkfontscale       mkhybrid          mkofm             mkzftree
mkfs              mkindex           mkpasswd          
mkfs.bfs          mkinitramfs       mksmbpasswd       

yyy ten mkinitramfs wygląda conajmniej podejrzanie. No to manem go. Okazuje się, że właśnie tego szukam. Więc wykonałam

mkinitramfs -o /boot/initrd.img-2.6.35.4
No teraz tylko edycja /boot/grub/menu.lst i powinno banglać.
(dopisanie przy jajkach linijki
initrd          /boot/initrd.img-2.6.35.4
)
No i reboot.
No jasny gwint. Nie będę za każdym razem czekała 10 minut aż mister Debian łaskawie się odpali.
Komunikat w trakcie waitania był mniej więcej taki. (napisałam sobie na kartce)
Begin:
running /script/local-top…blablabla
FATAL: Could not load /lib/modules/2-6…/modules.dep
Begin: waiting for root file syetem.
Szukałam błędu. Niby wina initrd. Dalej więc szukam. Ale nie to okazało się przyczyną.
Po prostu konfiguracja z 2.6.26.2 nie bardzo lubiała się z 2.6.35.4 no i wiecie, mogłam sobie modyfikować, ale jak DEPRACHED (czy jakoś tak) spotykały się z EXPERIMENTAL, musiały się gryźć. Chodziło o obsługę dysków pewnie.
Mamy już 11 dzień. Znowu szukam problemu. Okazało się, że wina leży zaś nie po mojej stronie, a po stronie konfigów kernela tamtego. Jak leciałam „od nowa”, on domyślnie i tak ją brał.
Rozwiązanie znalazłam na stronie http://kernel.xc.net/ tam dowiedziałam się jak powinien wyglądać config, że domyślnie bierze stary, a jak chcemy nowy, to jest on w
folder_z_source/arch/x86(lub inna architektura)/configs
tam są pliki dla 32 i 64 bitowej konfiguracji. I taką ścieżkę w xconfie podajemy żeby wczytał.  Dodajemy/modyfikujemy co trzeba według informacji podanych wcześniej. Zapisujemy do pliku .config w folderze ze źródłami, kompilacja jak powyżej. Instalacja paczek i śmiga. Żadnego czekania.
Szkoda tylko, że moje stery nvidii nie chcą się przeinstalować dla nowego kernela. Z tym że wszyscy mają problem. Widziałam jedno rozwiązanie, które polegało na modyfikacji kodu. Spróbuję go w najbliższym czasie. Na razie korzystam z iksów z driverem nvidii na starym jaju, a przed wejściem na nowe zmieniam na nv. No cóż, openGL i compiz fusion na nowym jajku to dopiero przyszłość. Na razie cieszę się z tego co mam.
Chciałabym podziękować tym, którzy służyli mi radą w tym trudnym dla mnie czasie. W szczególności (podaję nicki pod jakimi te osoby się pojawiają na #listekklonu):

  • -drummachinie
  • -lzsk’owi
  • -nikowowi
  • -kodxowi
  • - i tym co mieli podobny problem i dzięki nim znalazłam wpisy w sieci.


No dobra, sporo tego. Na szczęście już koniec. Operacja zakończona powodzeniem.
Cieszę się że nie poszło mi od razu. Sporo się nauczyłam. Wiecie jakie to fajne uczucie? To jak wejść na szczyt góry, czy latarni. Można użyć windy, wyciągu, kolejki, czego tam jeszcze. Ale można wejść na pieszo. Widoki te same, ale satysfakcja większa. Kurka, poniosło mnie lekko.