FLAME-WAR (Persze az is lehet, hogy igy rászoksz egy disztribúció-specifikus módszerre, amivel azután egy másik környezetben ott állsz megfürödve (vö: a YAST-ban kattins ide mag amoda). Nem hiszem hogy két file (bzImage es System.map) átmásolása a mc-vel a /boot-ba olyan bonyolult lenne (a modulokat már kitette a modules_install)
Tudna nekem valaki segíteni? Frissen rakott Debian 2.2r5 alatt menuconfig-gal összekattintgattam magamnak egy szimpatikus kernel-t. (ncurses miatt reklamált, valami ncurses???-dev felrakása után megjavult). Lefordítottam a szokásos módon (make mrproper, menuconfig, dep, clean, bzImage, modules, modules_install, install), bzImage után kiírja hogy 900k a kernel, ezután nézem az src könyvtárat, vmlinuz 2,6MB! Nekiálltam gyomlálni, amit engedett kitettem modul-ba, újrafordítás és még mindig 2,1 MByte pedig alig hagytam benne valamit.
Mit csináltam rosszul?
(ha ez számít valamit, a régi kernel-be editor-ral belenézve mintha a.out formátumú lenne az új meg ELF)
Szeretnék fordítani egy kernelt, ami ha jól sikerült, akkor szeretnék belőle csinálni egy .deb csomagot, hogy későbbiekben ha a gépen elszállna a vinyó, akkor egy telepítésnél ezen .deb kicsomagolásával menjen minden prímán. (beleértve a module-okat is)
Valahol olvastam rá megoldást, de nem találom sehol a weben
hahó, debian alatt nem így érdemes kernelt forgatni/installni
sokkal inkább a kernel-package csomagban levő make-kpkg paranccsal
ez legenerál neked a kernelt és a modulokat tartalmazó .deb file-t, amit utána dpkg-val installálhatsz, egyben rákérdez pl., hogy frissítse-e a lilot, akarsz-e bootlemezt csinálni belőle, és hasonló finomságok
a teljes parancs: make-kpkg --revision custom.1 kernel_image
ahol a custom.1-et a kedved szerint változtatgathatod
Megvan minden (menuconfig, dep, bzImage, modules, modules install), de a /lib/modules alatt csak a regi kernel moduljai vannak, a 2.4.18-as modulok sehol nincsenek.
Koszi a valaszokat, a kerdes igazabol teoretikus volt, de a halokartya pont kapora jott. B-)
---
Elkepzelheto, hogy a 7.1-es Susehoz adott gcc-vel (v2.95.2) nem tudok 2.4.18-as kernelt forgatni? Ugyanis most mar napok ota ezzel kuzdok. Odaig megy, hogy a bootolas elejen kipakol par pontot a kepernyore, majd olyan merevre fagy, hogy csak a ki/bekapcs segit. Forditas kozben viszont nincs hibauzenet.
Barmilyen modult - aminek a verzioszama megegyezik a kernellel, es nem forras, hanem mar modul (gcc-vel meg lehet csinalni) be lehet tolteni,annelkul hogy a kernelbe forditanad. A mdules.conf azert nem jo, mert mi van ha pl. olyaneszkozt hasznalsz,amit nem tamogat a kernel, de a bootolashoz kell, nem feltetlenul ugy, hogy arrol bootoljon, hanem hogy ne okozzon eroforras utkozest (nekme az alaplapi hpt raid vezerlo csinalta: spourius interrupt irq=7 es fagyas. A megoldas az initrd, ami szerkesztheto. A kernel betoltese utan ez kovetkezik, itt lehet barmilyen modul. utana jon csak a modules.conf. Az initrd egy gzip image, amit gzip-el kitomoritve valahova (/tmp) majd mount -o loop es oda bemasolod a sajat modulodat, majd gzip vissza, visszamasolni a /boot- ba es lilo. Ha valamelyikotoknek nem megy, ne szenvedjen vele, megirom reszletesen mailbe, en tokoltem vele 2 napot :-) Ja es felhivtam a Highpoint tech.supportot. :-) Ily modon minden modult be lehet forgatni az initrd-be.
gcc: nekem a 3.0.4-gyel is ment a kernelfordítás, viszont ezektől a moduloktól hülyét tudok kapni, annyira nem elegáns, ha nem a isztró gyári kernelét forgatom újra, hanem egy frisebbet teszek föl. bár ízlés dolga, de mostanság (hehe, negyedik kernelfordításnál de nagyképű ez a "mostanság", bocs) én sem pakolászom modulba a dolgokat.
amúgy én akár az angol, akár a magyar leírásokat nézegetem, kb. a dolgok fele, de talán kétharmada totál érthetetlen számomra. úgyhogy tuti, hogy egy csomó fölösleges dolog is benne van az általam fordított kernelben. szóval kicsit azért ellentmondásos, hogy "óvodásként" is rá vagyok szorulva a fordításra pár esetben, ugyanakkor nem maga a kernelfordítás menete, mint inkább a túl sok ismeretlen lehetőség miatt "nemszeretem" a kernelfordítás számomra
Már rég nem arról szól a dolog, hogy a kernel memória igényét csökkenteni lehessen.
Persze ez is lényeges, de sokkal fontosabb szerintem, hogy pl. egy hálókártya cseréjekor nem kell az egész kernelt újrafordítani.
Vagy pl. mint az Alsa driver, vagy a vmware driverek: külön, a kernel forráskódjától függetlenül is lehet minden szépet és jót a kernelbe illeszteni.
Én meg a modulokat nem szívlelem. Mindent fixen bele, de persze csak azt, amire szükségem van. Elég kicsi a kernel mérete így, és 190akárhány mega ram-ban nem érezhető. :)
Ja, én meg nem vagyok elég figyelmes. Szóval, a modul-kernel kérdés alátámasztása.
Sztem modulba érdemes fordítani, mert így, ha új kártyát teszel be, akkor könnyebb lesz drivert váltani (csak insmod újkártyamodul), nem beszélve arról, hogy ha esetleg két hálókártya van a gépedben, akkor így sokkal könnyebben csereberéled (csak a /etc/modules-ban kell a sorrenden változtatni, amelyik elsőre betöltődik, az eth0).
Hálókártyáknál ebből nincs baj, de pl. hangkártyáknál szokott gáz lenni abból, ha csak modulban van és nem kernelben (pl. SB16).
(Na igen, meg az se egészséges, ha beteszed pl. az IDE-támogatást modulba :-))
A tulip.c az alapból is benne van a kernelben. (Mármint belefordítható.)
Make menuconfig, aztán Network Device Support, 10/100 Mbit, és keresd meg ezt:
DECchip Tulip (dc21x4x) PCI support
No, és akkor ezt modulba.
Egyébként külső drivert, ha csak egy .c, akkor gcc -c, nem? (De ez most már nem ez a téma többé :-))
