Kernelfordítás Debian módra

Címkék

A Debian számos segédeszközt tartalmaz, amelyek segítségével saját kernelt fordíthatunk, de ennek ellenére sok Debian felhasználó a tradícionális utat választja. Az ausztráliai Linux magazin, a linmagau egyik friss cikkében azt az eljárást ismerteti lépésről lépésre, amellyel megszerezhetjük a kernel forrást, konfigurálhatjuk azt, debian csomagot készíthetünk belőle, majd azt a dpkg segítségével telepíthetjük a rendszerbe, mint bármelyik más debian (.deb) csomagot. A cikket megtalálod itt.

Neked mi a véleményed? Tényleg hasznos a make-kpkg vagy a legjobb mód a kernel fordítására a hagyományos eljárás (make dep bzImage)?

Írd meg a véleményed!

Hozzászólások

nem toroltem, "offtopic" minositest kapott "-1" kuszobbel lathato. bar a "flame" jobb lett volna, az "off" helyett...

Nekem tetszik az ötlet, bár néha muszáj a "hagyományos" eljárás, ha időt akarok spórolni és pl 4 szálon akarom párhuzamosan fordítani.
Asszem a make-kpkg doksiában nincs vagy nem találtam még meg a make -j4 ~ megfelelőjét :-(.



Üdv:

Csabka

sajat gepre mindig make modules modules_install bzImage, a make install-t hanyagolom, mert meg mingig az oldszkul lilo-t akarja hasznalni a telepitette es sokkaljobb grub helyett.

make-kpkg-nak ket letjogosultsaga van:

- akik nem merik vallalni a make bzImage modszert

- ha masik gepre kell vinni gyorsan, egyszeruen egy kernelt, a make-kpkg utolerhetetlen.

Az meg mese, hogy csak azert make-kpkg mert konnyebb upgradelni. Aki ezt mondja, sose ertette/csinalta a make bzImage modszert.

asd

make-kpkg másik előnye: make-kpkg-nak tudsz mondani kernel-image mellett egy modules target-et is. És akkor bemegy a /usr/src/modules könyvtárba is, és ott is mindent leforgat, és azokból is csinál .deb-eket. Így a kernel mellé egyből van lm-sensors-om, i2c-m, alsa-m, esetleg trunk 1.6-os radeon drm modulom, meg anyámkinja, ami nekem a woody-n kell, és amúgy nem lenne, vagy kínszenvedés, esetleg kismilió pöcsölgetés lenne.

Es ha leporgeted a kernel kezzel, a kernel imaget, meg a modulokat bemasolod egy helyre,

tar czvf kernel.tar.gz *

scp kernel.tar.gz user@host:

ott kibontod, bemasolod a helyere, beallitod a lilo-t vagy a grub-ot?

Imho ez sem sokkal tobb munka. Inkabb az dont, hogy ki mit szokott meg. Ebben az esetben sem kell a host gepen forditokornyezet.

További ellenérv: a biztonság. Egy tűzfalra pl. kifejezetten illetlenség :) gcc-t és egyéb fejlesztőeszközöket feltenni, de végül is ezt kiterjeszthetjük bármely olyan rendszerre, amelynek nem funkciója, hogy fejlessz rajta. Anélkül pedig nehéz kernelt fordítani :)

Hogy továbbmenjek: előfordul, hogy a kérdéses rendszeren túl kevés hely van (tettem fel Debiant 200 megás HDD-re, és még kellett egy kis hely a swapnak is), és már pl. a kicsomagolt kernel sem fér el.

Vagy pl. van egy baromi erős géped, és amire kernelt fordítasz, azok jóval gyengébbek, egy PI-166-on mondjuk nem nagy élmény lefordítani egy 2.4.xx kernelt ....

És akkor még nem is beszéltem arról, hogy egy esetleg elrontott kernel esetén mennyivel könnyebb visszatérni a korábbi állapothoz, mindössze egy dpkg -i ... parancsot kell kiadni.

Én is erre gondoltam, csak amikor használtam valahol elszált, hogy azt nem lehet több szálon fordítani... már nem tudom hogy hol...

de mintha csak a bzImage-t lehetett a modules -t nem... vagy valami ilyesmi.

Üdv:

Csabka

> make menuconfig; make dep && make modules && make modules_install.

make dep modules modules_install

Nem szebb így? :)

-Sygma

Ettől függetlenül a kernelforrást át kell vinni, ami körülményesebb, mint egy file átmásolása, több helyet is igényel, és feltételezi, hogy a make csomag fel van telepítve. Megoldható a dolog másként is, pl. egy chrootolt részre megcsinálni a modules_installt, azt összetarolni, és így vinni át, stb. Mindenesetre egy biztos: ha már ilyeneket kell használnod, akkor elég nehéz megindokolni, hogy ez miért is jobb, mint a make-kpkg.