We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Problem z kompilacją kernela


krzysztof_surowiec
02-09-2009, 10:52
Witam wszystkich
Też ostatnio ostro walczyłem z kompilacją kernela na RPS. W końcu się udało.
Poniżej opis co i jak robiłem dla zainteresowanych i sfrustrowanych

Sposób kompilacji kernela na serwerze RPS w OVH.

System operacyjny: Ubuntu 9.04 Server Edition

Potrzebne elementy:
* jądro systemu: [http://kernel.org/]
* standardowa konfiguracja kernela OVH: [ftp://ftp.ovh.net/made-in-ovh/bzImag...x-std-ipv4-32] dla kernela 2.6 lub nowszy pasujący do aktualnej wgrywanej wersji
* obraz startowego ramdysku OVH iscsi: [ftp://ftp.ovh.net/made-in-ovh/dedie/...csi-v1.63.img]
* binarka daemon iscsid OVH: [ftp://ftp.ovh.net/made-in-ovh/dedie/...-870.2-static]

Potrzebne pakiety:
* libncurses (dla make menuconfig)
* fakeroot
* initramfs-tools

Proces kompilacji i konfiguracji:
1. Uruchamiam OVH w trybie netboot.
2. Rozpakowuję paczkę z kernelem do '''/usr/src/'''.
3. Opcjonalnie tworzę link symboliczny


Kod:
cd /usr/src/
ln -s /usr/src/linux- linux

4. Kopiuję konfigurację kernela OVH do katalogu '''/usr/src/linux'''. Następnie zmieniam nazwę pliku konfiguracyjnego na '''.config'''.
5. Polecenie: '''make clean'''.
6. Polecenie: '''make menuconfig'''
7. Najpierw wybieramy opcję: '''Load an Alternative Configuration File''', pozostawiamy nazwę pliku na '''.config''' i ok.
8. Po załadowaniu pliku konfiguracyjnego kernel ma ustawione wszystkie niezbędne urządzenia i parametry, aby pasował do maszyn OVH. Teoretycznie jest to taki sam kernel jaki startuje z netboot.
9. W razie potrzeby dodajemy swoje opcje w konfiguracji kernela.
Tutaj uwaga: wszystko zaznaczałem jako opcja wkompilowania w kernel, wydaje mi się, że opcja kompilacji jako moduł nie działała później za dobrze.
10. Wychodzimy z konfiguracji zapisując ustawienia.
11. Polecenie: '''make bzImage'''.
12. Czekamy, aż kompilacja zakończy się bez błędów
13. Będąc w katalogu /usr/src/linux wykonujemy polecenie:


Kod:
cp System.map /boot/System.map-

14. Przechodzimy do katalogu /usr/src/linux/arch/x86/boot i wykonujemy polecenie:


Kod:
cp bzImage /boot/bzImage-
''Uwaga: katalog x86 może nie zawierać katalogu boot, zależy to od architektury na jaką budujemy jajko, może być amd64, i386 itp.''

W tym miejscu kończy się konfiguracja kernela.

Teraz robimy użytek z pozostałych plików, które pobraliśmy wcześniej z OV, czyli:
* obraz startowego ramdysku OVH iscsi


Kod:
cp initrd-iscsi-.img /boot/initrd-iscsi-.img

* binarka daemon iscsid OVH


Kod:
mv iscsid--static /sbin/iscsid

W pliku /etc/iscsi/version powinna się zgadzać wersja z tą w nawiasie

Ostatnim krokiem jest konfiguracja bootmanagera (przykład z Lilo).

''Plik /etc/lilo.conf''

Kod:
prompt
timeout=50
default=linux3
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
lba32
#serial=0,9600n8

image=/boot/bzImage-2.6.28.4
        label=linux1
        read-only
        root=/dev/ram0
        initrd=/boot/initrd-iscsi-v1.63.img
        append="libusual.bias=ub"

image=/boot/bzImage-2.6.28.4-2
        label=linux2
        read-only
        root=/dev/ram0
        initrd=/boot/initrd-iscsi-v1.63.img
        append="libusual.bias=ub"

image=/boot/bzImage-2.6.30
        label=linux3
        read-only
        root=/dev/ram0
        initrd=/boot/initrd-iscsi-v1.63.img
        append="libusual.bias=ub"
Zapisujemy plik. Ostatnie bardzo ważne polecenie '''lilo'''.
Bootmanager się zaktualizuje, mamy nadzieję, że bez błędów.

Należy sprawdzić czy w menadżerze OVH w sekcji netboot jest ustawiony tryb na (hd).

Gdy lilo się zaktualizuje pozostaje tylko '''restart'''.

Czekamy około 10-15 minut. Serwer bardzo wolno wstaje. W tym czasie mogą przychodzić powiadomienia o awarii systemu. Należy je '''zignorować''', do czasu, aż nie przyjdzie komunikat, że serwer przełączył się w tryb rescue. Wtedy wiadomo, że coś nawaliło i trzeba sprawdzić konfig kernela i od początku.

Aby sprawdzić czy system wystartował z nowym kernelem polecenie '''uname -a'''

Powodzenia

nixi
10-07-2009, 21:55
A to bardzo interesujące - rzeczywiście złośliwość przedmiotów martwych...

Wygląda na to, że podmontował ramdisk prawidłowo, a potem nie był w stanie wywołać z niego init-a. Ale z tego, co zrozumiałem, to poprzednio zacinał się przecież na dalszym etapie - czyli montowaniu już właściwej partycji, tak więc w trakcie wykonywania właśnie tego init-a z ramdysku...

Nie wiem już co o tym myśleć. Widzę kilka wariantów do sprawdzenia:
- Może obraz ramdysku jakoś złośliwie się uszkodził? Zobacz, czy cramfsck nie zgłasza w nim jakiś błędów. Rozpakuj sobie też ten obraz (cramfsck -x) i sprawdź, czy na pewno istnieje tam /sbin/init i czy ma nadane właściwe uprawnienia.
- Ewentualnie wypróbuj obraz z moimi modyfikacjami, do którego link podałem wcześniej w tym wątku.
- Sprawdź jeszcze raz, czy lilo.conf zawiera prawidłowe dane. Albo przypadkiem samo ponowne wywołanie "lilo" coś naprawi?
- Dopisz dla pewności w odpowiedniej sekcji lilo.conf linijkę append="init=/sbin/init", chociaż osobiście nie wierzę, żeby to coś zmieniło.
- Patrzyłem właśnie w Changelog i widzę, że w jądrze 2.6.30.1 były w stosunku do 2.6.30 jakieś zmiany w kodzie dotyczącym initrd, związane z zarządzaniem pamięcią. W prawdzie u mnie wszystko się uruchamia na 2.6.30, ale może Ty miałeś pecha, że błąd się ujawnił?

Rosomaczek
10-07-2009, 20:45
No cóż, on się chyba na mnie uwziął.
Tym razem wyrzuca:

Kod:
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
...co samo w sobie jest dość jasne, ale przyczyna tego problemu już niekoniecznie.
Niestety, przynajmniej u mnie, nie bardzo da się przewinąć ekran w górę, to wszystko co udało mi się zachować:


Rosomaczek
10-07-2009, 19:29
Cytat Napisał nixi
Jeśli model karty sieciowej jest taki sam jak u mnie (obsługiwany przez driver r8169), to raczej nie powinno już nic przeszkadzać, żeby jądro wystartowało prawidłowo na tym RPS-ie.
Driver jest taki sam, w ogóle `lspci -k` zwraca u nas praktycznie to samo.

nixi
10-07-2009, 17:45
Cytat Napisał Rosomaczek
No tak, zauważyłem właśnie, że masz wkompilowanego reisera, ale sądziłem, że popsułem coś jeszcze.
Jeśli model karty sieciowej jest taki sam jak u mnie (obsługiwany przez driver r8169), to raczej nie powinno już nic przeszkadzać, żeby jądro wystartowało prawidłowo na tym RPS-ie. Natomiast jeżeli sieciówka jest inna - to analogicznie do systemu plików, albo driver wkompilować w jądro, albo wrzucić odpowiedni moduł do initrd i stamtąd go załadować.

Rosomaczek
10-07-2009, 16:15
No tak, zauważyłem właśnie, że masz wkompilowanego reisera, ale sądziłem, że popsułem coś jeszcze. Teraz kilka godzin kompilacji i zobaczymy.

nixi
10-07-2009, 15:15
Cytat Napisał Rosomaczek
Jeśli chodzi o Twój config to błąd widać na vkvm -- nie potrafi podmontować partycji. Przypuszczam, że jest jakiś problem z załadowaniem modułu ext3.
A tak, nie napisałem, że używam ReiserFS i właśnie jego obsługa jest wkompilowana bezpośrednio w jądro, zaś ext3 jest jako moduł i żeby w Twojej konfiguracji wszystko się prawidłowo podmontowało, to trzeba zmodyfikować initrd, aby ten moduł załadować na odpowiednim etapie. Alternatywnym (może prostszym) rozwiązaniem będzie lekka zmiana konfiguracji jądra:

zamiast:
CONFIG_EXT3_FS=m

ustaw:
CONFIG_EXT3_FS=y

Potem trzeba oczywiście jądro od początku przekompilować, zainstalować, wywołać "lilo" i gotowe...

Rosomaczek
10-07-2009, 02:59
Cytat Napisał nixi
A na koniec trywialne pytanie - może Twój RPS się zwyczajnie nie restartuje prawidłowo.
Raczej nie, bo próbowałem na dwóch różnych. Oba to RPS1, ale sprzętowo są zupełnie inne. Jedyne co je łączy to oprogramowanie, więc myślę, że tam leży problem.

Rosomaczek
10-07-2009, 02:54
Cytat Napisał nixi
Nie sądze, żeby sprawa systemu miała tutaj znaczenie, raczej z jakiś powodów jądro nie chce wstać, przez co /sbin/init nie zostaje nigdy wywołany, stąd brak śladów w logach.
Jeśli chodzi o Twój config to błąd widać na vkvm -- nie potrafi podmontować partycji. Przypuszczam, że jest jakiś problem z załadowaniem modułu ext3. Od paru lat nie stosuje modułowych kerneli nigdzie poza desktopami, więc mogłem coś przeoczyć. Spróbuję wkompilować potrzebne moduły na stałe i zobaczymy.

Co do braku błędów -- może być albo tak jak mówisz, ale także jest taka możliwość, że nie umie dogadać się z iscsi, stąd nie ma gdzie tych logów zapisać. Hm... Ale skoro tak, to powinien bez problemu zalogować jeśli podmontuję /var/log lokalnie na pendrivie i chyba będę musiał tak zrobić.

No nic, zobaczymy czy teraz się uda, dzięki za dotychczasową pomoc.

nixi
07-07-2009, 16:40
Poniżej załączam rezultaty z mojego RPS-a:
lsmod Załącznik 94
lspci -k Załącznik 95

Nie sądze, żeby sprawa systemu miała tutaj znaczenie, raczej z jakiś powodów jądro nie chce wstać, przez co /sbin/init nie zostaje nigdy wywołany, stąd brak śladów w logach.

I tutaj zastanawiające zaczyna mi mi się wydawać to opóźnienie 15 minut, które obserwowałem u siebie. Nigdy nie próbowałem bootować RPS-a w trybie vKVM, ale ktoś wcześniej pisał, że problem potrafi być z przyzananiem maszynie adresu przez udhcpc na etapie initrd. Może tu jest problem? Jeszcze jeden aspekt - nie chce mi się wierzyć, żeby to mogło mieć jakikolwiek wpływ, ale za każdym razem, jak restartowałem RPS-a, to sobie pingowałem cały czas zarówno główny adres, jak też failover. Może jakimś cudem potrzeby jest właśnie taki zewnętrzy bodziec? Z drugiej jednak strony RPS mi się kiedyś sam zrestartował w nocy i grzecznie sobie wstał bez takiego nachalnego pingowania... Jednak interesujące tutaj będzie, czy Twoja maszyna zacznie w ogóle odpowiadać na pingi (na głównym ip).

Dla pewności - podaję jeszcze link, gdzie można pobrać troszkę przeze mnie poprzerabiany initrd-iscsi.img (takiego właśnie używam). Niby nic specjalnego tam nie zmajstrowałem w stosunku do oryginału z OVH, ale kto wie:
http://www.sendspace.pl/file/d3ab6e1283398630f9f432e

A na koniec trywialne pytanie - może Twój RPS się zwyczajnie nie restartuje prawidłowo... Takie mam jeszcze podejrzenie, że problem może być innej natury, że na przykład coś na koniec nie udaje się prawidłowo odmontować i przez to maszyna tkwi w jakimś dziwnym stanie, zamiast się zrestartować. Próbowałeś zrobić sprzętowy reboot z poziomu managera OVH?

Rosomaczek
07-07-2009, 13:37
Jeszcze jedna mała prośba. Mógłbyś mi wrzucić `lsmod` z jakiegoś RPS-a gdzie masz to jajko i może jeszcze `lspci -k` (to drugie mniej ważne, tylko do porównania)? Z góry dzięki...

Rosomaczek
07-07-2009, 02:01
Cytat Napisał nixi
Bootuję RPS-a z iSCSI - lilo.conf (było już we wcześniejszym wątku, ale powtórzę)
Ja też tak zrobiłem, wziąłem config ovh, jajko 2.6.29.5, pozaznaczałem parę rzeczy w configu (m.in. te, które podałeś), zassałem initrd-iscsi.img i iscsid, ale jak się okazało na rps były już najnowsze wersje ovh. No i niestety nie chce to nijak działać przy bootowaniu via "hd", natomiast via vkvm działa w najlepsze.

Godzinę temu skończyłem kompilować jajko z Twoim configiem i też nie wstaje. Pewnie też nie będzie logów. Powoli kończą mi się pomysł... Co jeszcze mogę sprawdzić? Czego może brakować w systemie, co nie przeszkadza przy bootowaniu via vkvm, a przeszkadza gdy bootuje via "hd"?

nixi
06-07-2009, 21:57
Cytat Napisał Rosomaczek
Dzięki... Jedno pytanie. Bootujesz RPS-a bezpośrednio z dysku sieciowego, czy też np. podmontowałeś /boot na /dev/uba i zaczynasz stamtąd?
Nie, nie - żadnego bootowania z pendrive (tak na marginesie - w moim systemie mam go jako /dev/sdb, a nie /dev/uba - z powodu konfiguracji jądra, wybranej z premedytacją: "# CONFIG_BLK_DEV_UB is not set" oraz "CONFIG_USB_STORAGE=m").

Bootuję RPS-a z iSCSI - lilo.conf (było już we wcześniejszym wątku, ale powtórzę):

boot = /dev/sda
install = text
timeout = 50
default = Linux
lba32
prompt

image = /boot/bzImage
label = Linux
read-only
root = /dev/ram0
initrd = /boot/initrd-iscsi.img

Rosomaczek
06-07-2009, 21:00
Cytat Napisał nixi
W załączeniu pełna konfiguracja dla jądra 2.6.30 działającego u mnie na RPS1 (używam dystrybucji Slackware 12.2, ale to nie powinno mieć znaczenia).
Dzięki... Jedno pytanie. Bootujesz RPS-a bezpośrednio z dysku sieciowego, czy też np. podmontowałeś /boot na /dev/uba i zaczynasz stamtąd?

W ogóle zastanawiam się, czy nie brakuje mi czegoś w samym systemie, ale skoro wstaje z poziomu vkvm to chyba wszystko zrobiłem tam jak należy. Hm... Dziwne...

nixi
06-07-2009, 20:46
W załączeniu pełna konfiguracja dla jądra 2.6.30 działającego u mnie na RPS1 (używam dystrybucji Slackware 12.2, ale to nie powinno mieć znaczenia).

Załącznik 93

Na pewno można w nim wyłączyć trochę modułów, gdyż władowałem sporo rzeczy, które zapewne nigdy nie będą mi ani nikomu innemu potrzebne, a z tego powodu "make modules" trwa troszkę dłuuugo... Wszystko, co potrzebne, żeby RPS wstał jest natomiast wkompilowane bezpośrednio w jądro.

Pozostałe szczegóły instalacji opisałem wcześniej w wątku "Kernel na RPS".

Rosomaczek
06-07-2009, 20:31
Cytat Napisał ollerm
kiedyś to już chyba było, nawet niedawno. Podobno RPS z HD wstaje jakieś 15 minut
Wiem o tym, ale on niestety nie chce wcale wstać. Zostawiłem go na całą noc dla pewności. A z poziomu vkvm wstaje w kilka minut i działa bez przeszkód.

ollerm
06-07-2009, 20:29
kiedyś to już chyba było, nawet niedawno. Podobno RPS z HD wstaje jakieś 15 minut

Rosomaczek
06-07-2009, 18:02
Witam

Mam problem z kompilacją kernela na RPS1 (Debian). Generalnie wydaje mi się, że znam się na tym całkiem nieźle, już kilka lat temu przygotowywałem własne configi i zestawy patchy na jądro, jednak teraz z jakiegoś powodu nie mogę sobie poradzić. Główny problem jest taki, że jądro działa dobrze na vkvm, natomiast nie działa wcale w trybie "hd". Myślałem, ze problem dotyczy może karty sieciowej, ale niestety nie ma nic w logach, więc RPS albo wcale nie bootuje albo nie jest w stanie podmontować sobie przestrzeni dyskowej via ISCSI.

Mówiąc krótko na vkvm wszystko działa, a w "hd" nic i brak jakichkolwiek logów, więc nie mam pomysłu co dalej. Chciałbym wykluczyć błędy w configu mojego jajka więc mam małą prośbę.

Czy ktoś z Was mógłby mi udostępnić swój config który na pewno działa na RPS1?

Będę także wdzięczny za wszelkie rady dotyczące tematu, dodam, że zapoznałem się oczywiście ze starszymi wątkami na tym forum, proszę więc nie odsyłać mnie do archiwum.

Z góry dzięki za pomoc.