Cesta do hlubin kompilace jádra - 1

31. 8. 2005 | Antonín Kolísek | Návody | 35246×

Kompletace potřebného software. Kde vzít zdrojové kódy a které použít. Rozdíly kompilace jader 2.6 a 2.4.

Na úvod

Kde kdo byl určitě již postaven před problém typu něco nefungovalo, něco nebylo podporováno. Nebo z čisté zvědavosti prostě stál před výzvou a někdy obávaným úkolem kompilovat vlastní kernel. Pro člověka v Linuxu ne moc zběhlého to může být docela zapeklitá situace. Kompilace sama o sobě je krok, který zvládne téměř každý, kdo pracuje s Linuxem pár týdnů. Mnohdy se ale stane, že i když je vlastní jádro dobře přeložené, je ještě více pomalé než to distribuční a nebo v něm nefunguje plno věcí, jak by mělo.

Zde jsem se zhostil úkolu popsat v několikadílném seriálu nejen samotnou kompilaci, ale především poukázat na to co, kdy a proč dát a nebo nedat do našeho jádra, a co vše je k tomu potřeba. Z obrovské rozsáhlosti jednotlivých subsystémů jádra se pokusím poukázat na ty důležité a nezbytné pro správnou činnost. U některých sekcí se zdržím více. U některých méně nebo téměř vůbec, především tehdy, jedná-li se o některý exotický hardware nebo funkci v normálních podmínkách nepotřebnou. Začátečník i pokročilý uživatel by si měli přijít na své. Právě pro ty je tento seriál směřován.

Zdrojové kódy

Pro kompilaci kernelu je potřeba obstarat si zdrojové kódy. Je možné použít ty, které jsou přibaleny v distribucích (u některých distribucí to doporučuji, pokud nechcete ztratit některé její funkce a vlastnosti), což není pravidlem. Je možné použít i zdrojové kódy jádra zcela čisté, bez přídavných záplat a doplňků, jimiž se liší různé distribuce. Osobně se přikláním k použití zdrojových kódů, jak se říká, přímo od výrobce tzv. vanilla kernel.

Vždy se nejprve podívejte na www.kernel.org, kde je vidět aktuální situace okolo verzí Linuxu. Tam je možné stáhnout čisté zdrojové kódy - vanilla karnel.

V článku Patchsety pro kernel jsou popisovány různé patchsety, tj. sady patchů připravené pro aplikaci na vanilla jádra.

Po stažení zdrojových kódů (např. linux-2.6.13.tar.bz2) budeme potřebovat pro jejich rozbalení programy GNU tar, bzip2 (pro .tar.bz2) nebo gzip (pro .tar.gz), které jsou součástí všech distribucí.

Má-li někdo starší verzi zdrojových kódů, má možnost je aktualizovat aplikováním záplat (tzv. patchů). Musí být však splněna podmínka: aktualizovat se musí postupně, takže pokud chci zdrojové kódy verze 2.6.10 aktualizovat na 2.6.12, musí se aplikovat nejprve patch na verzi 2.6.11 a následně patch na verzi 2.6.12. Pro patchování jádra je potřeba mít program patch. Pokud již systém obsahuje zdrojové kódy (nalézají se v /usr/src/) a chceme je záplatovat/aktualizovat, provedeme nakopírování patche na příslušné místo a aplikujeme jej:

cp patch-2.6.13.bz2 /usr/src/linux-2.6.12
bzip2 -dc patch-2.6.13.bz2 | patch -p1

nebo

gzip -cd patch-2.6.13.gz | patch -p1

V případě, kdy zdrojové kódy ještě v systému nemáme, rozbalíme patřičný balíček, např:

cp linux-2.6.13.tar.bz2 /usr/src
tar -xvjf linux-2.6.13.tar.bz2

nebo

tar -xvzf linux-2.6.13.tar.gz

Dále je vhodné vytvořit symbolický link na adresář se zdrojovými kódy.

cd /usr/src
ln -s linux-2.6.13 linux

Potřebný software

Po rozbalení je vhodné se podívat na soubor /usr/src/linux/Documentation/Changes, který obsahuje mimo jiného také souhrn programů a jejich verzí potřebných pro kompilaci a správný běh jádra. To se může čas od času měnit, proto je vhodné ověřit si, zda náš systém obsahuje požadované programy.

Kompilace jádra

I když nyní trochu předběhnu, popíši zde postup kompilace jádra. Nutný předpoklad je mít vybrané potřebné součásti kernelu před vlastní kompilací. Výběru komponent se budou týkat následující díly tohoto seriálu. Uvádím zde postup předčasně pro případné zájemce a pro ty, kdo chtějí experimentovat a zkusit si sestavit vlastní kernel ihned.

1. V první fázi, pokud kompilujeme jádro ze stávajících zdrojových kódů poprvé, je nutné provést make mrproper, přeskočení tohoto kroku je častou příčinou neúspěšné kompilace nebo vytvoření chybně pracujícího jádra. Pokud jsme však již jádro kompilovali a provedeme make mrproper, pak dojde ke smazání také souboru .config, který ještě můžeme potřebovat.

   make mrproper

2. Pokud budeme kompilovat ze zdrojových kódů, ze kterých se již jádro dříve kompilovalo, musíme smazat existující hlavičkové a binární soubory:

   make clean

3. Jestliže jsme již jádro kompilovali (např. 2.6.12), a chceme použít existující konfiguraci i pro kompilaci jádra 2.6.13, použijeme existující .config:

   make oldconfig

4. Nyní již následuje výber součástí jádra. Zde máme možnost použít několik režimů:

   make config

   příkazová řádka, postupné potvrzování, velmi zdlouhavé

   make menuconfig

   menu v textovém režimu

   

   make xconfig

   menu v grafickém režimu, používá knihovny Qt

   

   make gconfig

   menu v grafickém režimu, používá knihovny GTK+2

   

5. Výběru komponent jádra se budu věnovat v dalších dílech. Nyní následují další kroky po výběru komponent.

6. Sestavení jádra a modulů se mírně liší u jader řad 2.4 a 2.6:

   Jádra 2.4 a nižší

   1. make dep - kontrola závislostí
   2. make bzImage - sestavení kernelu
   3. make modules - sestavení modulů

   Jádra 2.6

   1. make - sestavení kernelu a modulů

7. make modules_install - instalace modulů do /lib/modules/linux-X.Y.Z

Instalace zkompilovaného jádra

Zatímco kompilaci je možné provádět jako běžný uživatel, pro instalaci jsou potřeba práva superuživatele.

Po kompilaci nakopírujeme obraz jádra + další soubory do adresáře /boot. Doporučuji vytvořit si pro přehlednost i příslušný podadresář:

mkdir /boot/2.6.13
cp /usr/src/linux/System.map /boot/2.6.13
cp /usr/src/linux/vmlinux /boot/2.6.13
cp /usr/src/linux/arch/i386/boot/bzImage /boot/2.6.13
cp /usr/src/linux/.config /boot/2.6.13 - zálohujeme .config

Závěrečným krokem je nastavení zavaděče LILO nebo GRUB:

LILO:

image = /boot/2.6.13/bzImage
label = linux-2.6.13
root = /dev/hda1 # oddíl, na kterém je kořenový adresář /

Nezapomeneme nainstalovat LILO do MBR příkazem lilo.

GRUB:

title Linux-2.6.13
root (hd0,0)
kernel /boot/2.6.13/bzImage ro root=/dev/hda1

Závěr

Úvodní díl nás seznámil s vlastní kompilací. V následujícím díle se zaměřím na zjišťování informací o našem hardware, které bude potřeba pro výběr jednotlivých komponent.

       

Komentáře

Diskuse byla administrátory uzamčena

[D-Evil]

make install za vás kopírovaní do /boot provede (pokud se spokojíte s tím, že jsou všechny soubory přímo v /boot) a stejně tak za vás provede i znovuzapsání bootloaderu (LILO, Grub stačí nastavit, nemusí se zapisovat znova). Myslím, že tohle se hodilo do článku uvést. Jinak chválim.

[Michal Čihař]

pokud se spokojíte s tím, že jsou všechny soubory přímo v /boot

Spíš pokud se spokojíme s tím, jak to chce vendor distribuce. Při instalaci se volá /sbin/installkernel.

[Zdeněk Štěpánek]

Zdravim

Doporucovat make clean pred kazdou kompilaci je docela zbytecne. Pri make clean se vymazou veskere vysledky kompilaci a i pri sebemensi zmene v jadru se vse kompiluje znova. Coz ponekud trva, ze. Gcc prece pozna, kterej zkompilovanej soubor muze zachovat a kterej musi prekompilovat, tak to nechavam na nem.

Je pravda ze obcas to zlobi, takze make clean davam jen pokud nastavim jiny typ procesoru (to by se stejne kompilovala vetsina jadra znova). Jinak ne.

Zdenek

[azurIt]

blbost, mne to robilo problem takmer vzdy (jadro sa neskompilovalo, vyhodilo to nejake chyby)

[J]

Zajimave, osobne make clean pouzivam vyhradne pokud menim neco primo v kernelu, ale protoze vetsinou jde jen o pridani odebrani modulu, je to naprosto zbytecne. Ovsem tak ci onak se mi jeste nestalo, ze by se mi kernel neprelozil.

[azurIt]

ked menis len moduly, tak je to jasne, moduly sa skompiluju aj bez jadra (resp. nemusis kompilovat jadro, ono si to vsetko potrebne skompiluje)

[Luboš Doležel (Doli)]

No, patchoval jsem jádro už všelijak a vždycky to dopadlo dobře.

[Marekhttp://www.root.cz/clanky/nova-softwarova-sklizen-31-8-2005/nazory/vsm Turnovec]

Zajímavé, mě to nedělalo problém snad nikdy. A to možná ani s kernelem 2.4...

[Michal Kubeček]

Ono je to spíš tak, že problémy byly u jader řady 2.4 a starších. U řady 2.6 byl proces kompilace a linkování výrazně pročištěn, takže se bez 'make clean' obejdete.

[Pavel Janousek]

Naopak je vice nez vhodne, zejmena u RPM jader z produkce Red Hat Inc. dat pred prvni kompilaci make mrproper (aspon na 2.4.X), modri uz vedi...

[magdalenka]

Konečně ucelený článek, ze kterého to pochopí i taková lamka jak já...

[misk0]

http://avc.sh.cvut.cz/archiv/index.php?id=1041&rid=212&offset=0&select=0

[Xóža Hňabaj]

Zajimalo by mě, jak moc je nutné provádět make clean při nové kompilaci jádra z už jednou použitých zdrojáků. Když například zjistím, že by se mi hodilo mít ještě nějaký modul v jádře, tak překladač může použít *.o soubory které už jednou zkompiloval. Nebo se mýlím?

[Antonín Kolísek]

Pokud je potřeba dodělat modul, tak make clean také nedávám. Když něco doplním přímo do jádra, tak si nedovolím nedát make clean. On člověk nikdy neví. Jinak make clean je na místě v případě, že kompilace nedopadne dobře, nebo jádro nějakým způsobem nepracuje správně.

[azurIt]

ono ked si chces skompilovat moduly, tak jadro kompilovat vobec nemusis, proste preskocis krok 'make bzImage'

[camlost]

Ahoj autore , včera jsem ti slíbil zdrcující kritiku, tady ji máš:

• ještě více pomalé = ještě pomalejší
• plno věcí,jak = plno věcí, jak (mezera)
• zdrojových kódů jak se říká přímo = zdrojových kódů, jak se říká, přímo

No, dál to vypisovat nebudu, ale po téhle stránce jsi to nezvládl.

cd /usr/src ln -s linux-2.6.13 linux

:-O A na to jsi přišel jak? Co je na tom? Přečti si http://linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html - za tohle si pochvalu nezasloužíš.

cp /usr/src/linux/.config /boot/2.6.13 - zálohujeme .config

Není na tohle nějaká šikovná volba v kernelu? Třeba CONFIG_IKCONFIG?

[Antonín Kolísek]

Beru kritiku. A proč by ne? Rád jsem se přiučil. Ten symlink jsem nevěděl :)

Ad .config - ano,linux-2.6 umí od jisté doby aby v /proc/config.gz byla konfigurace jádra. Ale to jen toho stávajícího. Pokud se chci podívat jak jsem to měl v tom předchozím, to už je jaksi smůla. Proto zálohovat .config :)

[Lukas]

Muze mi nekdo prosim osvetlit pointu odkazovaneho clanku na linuxmafia? Jaksi jsem to s tim symlinkem nepochopil, v cem je takovy vazny problem? http://linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html

diky, Lukas

[Michal Kubeček]

Problém je v tom, že aplikace nekomunikují přímo s jádrem ale s knihovnou libc. Proto by měly být při kompilaci includovány hlavičkové soubory, které odpovídají jejímu interface.

[JaSan]

Volakedy sa robievali taketo symbolicke linky:

/usr/include/linux -> /usr/src/linux/include/linux
/usr/include/asm   -> /usr/src/linux/include/asm-i386

V /usr/include/linux a /usr/include/asm vsak maju byt hlavickove subory, za pouzitia ktorych bola skompilovana kniznica GNU libc a nie subory z naposledy skompilovaneho kernelu.

Dnes sa pri kompilacii GNU libc pouzivaju dokonca mierne upravene include subory z balika linux-libc-headers, ktory dava dokopy Mariusz Mazur. Tento balicek sa da najst na adrese: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

Pouzitie najnovsich hlavickovych suborov pri kompilacii GNU libc neznamena ze je mozne pouzit uz len Linux verzie takej ake su hlavickove subory alebo vyssej. To sa zabezpecuje volbou --enable-kernel=X.Y.Z pri kompilacii glibc.

[zde]

Přiznám se že tomu absolutně nerozumím. Je jasné že glibc potřebuje pro vlastní kompilaci headery z jádra, aby vědělo čísla syscallů, ioctl-ek, a offsety jednotlivých položek v různých struct-ech.

Ale měl jsem za to, že glibc poskytuje API na tak vysoké úrovni, že kernelovské API je skryto, a glibc dělá překlad (viz třeba struct stat).

Je to tedy jinak? Pro překlad a linkování aplikace nad glibc potřebuji kernel headers?

[Robert Krátký]

No, dál to vypisovat nebudu, ale po téhle stránce jsi to nezvládl.

Chyby tohoto typu jdou na moji hlavu.

cp /usr/src/linux/.config /boot/2.6.13 - zálohujeme .config

Není na tohle nějaká šikovná volba v kernelu? Třeba CONFIG_IKCONFIG?

O konfiguračních volbách budou další díly, ne? Pokud tím myslíš, že zálohování souboru .config je díky možnosti uložení konfigurace do jádra zbytečné, tak s tím nesouhlasím. Mnohdy se totiž může hodit konfigurační soubor k jádru, které ti zrovna neběží.

[camlost]

Mnohdy se totiž může hodit konfigurační soubor k jádru, které ti zrovna neběží.

Nechci (a snad to ani nedělám) se hádat o "mnohdy" - obvykle mi doma běží jeden kernel (říkejme mu) stabilní, další - originální distribuční - se toulá někde na disku a třetí - up-to-date - právě kompiluju. Věren "podle sebe soudím tebe" jsem předpokládal, že ostatní jsou na tom stejně.

Ještě ke včerejší debatě - napadl mě argument proti make bzImage. (Omlouvám se za nenavazující příspěvek, kdyby to vadilo, tak ho někdo smažte.) Kdysi jsem na nějaký stařičký stroj (12 MB RAM?, 200 MB hdd) instaloval linux. Hledal jsem rozumně aktuální distribuci, kterou by bylo možné nainstalovat. Zkoušel jsem RockLinux. Jeho instalační balíčky jsou baleny bzip2kou a vůbec se mi nepodařilo nainstalovat base_system, protože to prostě nešlo rozbalit. Včera mě napadlo, že může existovat platforma, na které není bzip2 z nějakého důvodu použitelný nebo neexistuje. Protože je snaha, aby byl linux přenositelný, měl by být přenositelný i proces kompilace kernelu. Tím spíš, že je algoritmicky snadno zvladatelné. (Možná je to příliš umělá myšlenková konstrukce .)

Jinak k těm adresářům v /boot - tam se mi líbí trošku jiný systém. (But hey, this is a free software, you are free to use it your own way.) Už asi dva roky si říkám, že to tak udělám, ale ještě k tomu nedošlo - sdílená /boot partition. V /boot by pak byly adresáře pro jednotlivé distribuce. V případě grubu s tím není problém, s lilo by asi pomohl symlink /etc/lilo.conf -> /boot/<distro_id>/lilo.conf.

[Antonín Kolísek]

bzImage sem opravdu teď nepatří, to je jen mezi mnou a tebou (nemyslím šéfredaktora) a včera se to vyřešilo :))

.config - určitě byl kde kdo postaven před problém, kdy dal něco jako modul, nebo do jádra a ono to nepracovalo správně, protože to bylo právě naopak :) (třeba takový agpgart a Nvidia). No jo,ale co když to mám právě v aktuálním jádře "asi" špatně a nevím jak jsem to měl v tom minulém kdo to bylo OK? Ha, mám zálohy .config :)) Takže k tomu to je dobré.

Sdílená /boot parition:

1/ Každý nemá několi distribucí aby musel /boot sdílet. 2/ speciální oddíl pro /boot pochází hlavně z historie, kde to bylo kvůli LILO zavaděči, který neuměl číst za 1024 cylindrem. Když to vezmu kolem a polem, tak nevidím rozumný důvod, prč dávat /boot na speciální oddíl.

[camlost]

Takže k tomu to je dobré.

To nezpochybňuju. Jen to není nutné, protože ten .config získáš z běžícího kernelu, pokud jsi nastavil CONFIG_IKCONFIG=y. Což má tu výhodu, že se ti to udělá samo, pokud přenášíš .config mezi jednotlivými verzemi. (Já to nedělám, .config používám jen v rámci např. 2.6.12.x vzhledem k současnému způsobu vývoje.) Představ si, že zapomeneš na to cp .config ... a smažeš zdrojáky. No, tobě to třeba nevadí, protože kompiluješ kernel skoro tak často jako já a znáš ty volby.

Samostatný oddíl na /boot je ve stroji s jedním linuxem asi skutečně k ničemu. Mrknu se na notebook, jestli tam mám /boot samostatně... aha, nemám. Tak buď je to náhoda, nebo mám zrovna v tomhle asi jasno . Btw. ale doma mám 3 disky a jen na jednom z nich mám 12 partition. A níž nejdu. ))

[Antonín Kolísek]

OK, ale mám-li v jádře CONFIG_IKCONFIG=y, tak se mohu podívat jen na konfiguraci běžícího jádra. Abych zístil, jak je to v jiném kernelu, musím rebootovat a to někdy není příliš výhodné.

[Marcel Šebek]

2/ speciální oddíl pro /boot pochází hlavně z historie, kde to bylo kvůli LILO zavaděči, který neuměl číst za 1024 cylindrem. Když to vezmu kolem a polem, tak nevidím rozumný důvod, prč dávat /boot na speciální oddíl.

Jeden důvod bych vědel. Když uživatel chce používat reiser4 jako kořenový filesystém a grub jako bootloader, tak mu nezbyde než buď opatchovat grub nebo udělat extra oddíl pro /boot a jako filesystém dát jeden z mnoha podporovaných.

[David Jaša]

To platí i pro mnohem rozšířenější XFS.

[zde]

Proboha mějte rozum a nepoužívejte grub.

[Marcel Šebek]

Proč?

[zde]

1) je to mamut 2) neumí nic, co by neumělo Lilo 3) nenačte kernel z FS, který neumí. 4) je to mamut. Jestli něco z toho není pravda, rád se to dozvím.

[Antonín Kolísek]

Když někdo používá ext2/ext3fs (a takových není málo), nemá šifrovaný FS (takových je většina) a nedělá mu (GRUB) problémy, tak proč používat LILO?

[Lynn]

proč grub? třeba proto, že neměl problém se nainstalovat na linux native, kdežto lilo protestovalo... a na mbr proste bootloader nechci...

[David]

no a umi uz Lilo takove pekne graficke prostredi pri bootu, s vyberem images, jako to ma Grub? Ne ze by to bylo dulezite, ale spoustu jinych veci mam taky jenom proto, ze se mi libi. :)

[Petr]

Obrázky umí. Někde sem dokonce viděl aj animované lilo (-:

[b0rmann]

Když to vezmu kolem a polem, tak nevidím rozumný důvod, proč dávat /boot na speciální oddíl.

Jednoduchy priklad - mam cryptovany souborovy system. Bez samostatneho necryptovaneho /boot bych to ani nahodou nerozjel :)

[Robert Krátký]

obvykle mi doma běží jeden kernel (říkejme mu) stabilní, další - originální distribuční - se toulá někde na disku a třetí - up-to-date - právě kompiluju.

U mě to vypadá tak, že po kompilaci a instalaci nového jádra ještě ponechávám nějakou dobu na disku to, které nahrazuji. Když je s nově zkompilovaným něco v nepořádku, pak se mi hodí .config z toho předchozího, o kterém vím, že fungovalo správně.

Jinak k těm adresářům v /boot - tam se mi líbí trošku jiný systém. (But hey, this is a free software, you are free to use it your own way.)

Asi tak. Taky to dělám jinak, ale i popsaný způsob má své výhody. Je pravda, že samotnou kompilaci provádím ve svém $HOME, ale při přípravě článku mě nenapadlo na to autora upozornit.

[JaSan]

Pokial sa nemylim, Linux si hlada subor System.map tak, ze najprv skusi /boot/System.map-"verzia" a potom /boot/System.map. To znamena ze na System.map sa nemusi vytvarat symbolicka linka, ale nehovori to vobec o tom, ze mozes hodit System.map mimo /boot.

Ak sa mylim, prosim opravte ma.

[Marek Turnovec]

A kdo rika, ze ten kernel musi bezet? K cemu je pak asi scripts/extracts-ikconfig? To presne dela ta volba CONFIG_IKCONFIG. To ze je to z beziciho kernelu pristupne v /proc/config.gz, to uz je jen tresnicka na dortu.

[Michal Marek (twofish)]

http://linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html

Píše se rok 2005...

[camlost]

Dekuji za pripomenuti. Ono se to od te oby zmenilo? :-O

[xxx]

Myslim, ze je to velmi vydarene (ma to hlavu a patu, je to vecne...). Doufam, ze ti forma vydrzi a tesim se na dalsi dily, kde to vezmes trochu podrobneji a upozornis nas na mozne problemy (pri prekladech se spatnym gcc apod.).

[jgv]

Hezky clanek, akorat mozna by neskodilo pridat jak je to s cislovanim jader, ktera jsou stabilni/testovaci.

[Antonín Kolísek]

Tohle jsem v článku měl,ale po uvážení redakce to bylo odstraněno :/

[taif]

Hehe, urcite vis, ze od 2.6.x je vsechno uplne jinak ... jinak za _REAL_ stable (v 2.6) povazuji 2.6.11.12.

[Zdenek]

Hezké, ale v Debianu potřebuju ještě vyrobit jakýsi /boot/initrd.img-2.6.x-686, který má cca 4MB. Pravděpodobně jej vyrábějí skripty z balíčku initrd-tools, ale k čemu je to dobré, a hlavně proč to neudělá přímo make install, to je mi záhadou.

[Antonín Kolísek]

K čemu je potřeba initrd a jak se vyrábí popíši v jedno z dílů.

[Martin]

Ak pridas do kernelu podporu suboroveho systemu, ktory pouzivas (nie ako modul), tak ho potrebovat nebudes.

[Michal Kubeček]

To není také tak úplně pravda. Přesněji řečeno to není vůbec pravda. Jen namátkou:

• kořenový filesystém je na řadiči, jehož driver je jako modul
• kořenový filesystém je softwarovém RAIDu
• kořenový filesystém je na NFS
• …

[hrobar]

Ako sa kompiluje jadro v debiane najdes tu: http://www.debian-administration.org/articles/202 Pouzivam debian asi 2-3 roky a napriek tomu jadro kompilujem standardnym sposobom. K tomu make clean, v zivote som ho nepouzil a to som v jadre menil aj veci priamo v jadre. Mam zasebou doslova stovky kompilacii(rad spekulujem) a nikdy som s tym nemal problemy tak neviem.

[Zdenek]

ext2 59952, ext3 108186, reiserfs 227060, jfs 170585 size -t /lib/modules/2.6.8-2-686/kernel/drivers/ide/pci/* 202607

Ve srovnání s (gzipnutým!) 4MB initrd je to směšně málo. Nebylo by tedy lepší s initrd vůbec nešaškovat, a mít ovladače pro obvyklé IDE čipsety a filesystémy přímo v jádře? Zdá se mi že debianové to s tou "generality through obscurity" docela přehánějí. :(

[Michal Čihař]

To samé dělají všechny binární distribuce .

Jinak tam určitě budou i ovladače pro SCSI, RAID, LVM, programy na sestavení RAIDu a LVM atd...

[trekker.dk]

Použití initrd je v debianu defaultní, což ale neznamená, že je to povinné.

[###]

Co myslíš, tím defaultní?

[trekker.dk]

Viz odkaz o něco výše - jádro se obejde bez initrd, když si ho tak nastavíte. Default nastavení (tj. .config soubor z balíčku kernel-source) je takové, že se initrd při startu používá

[Pavel Janousek]

No vite on je docela problem vyrobit monoliticky kernel, ktery by mel slusne moznosti a zaroven byl bootovatelny z FDD... - myslim tim realnou FDD a bootovani via loadlin nebo neco podobneho...

[taif]

Souhlas, nejde jen o FDD, proste kernel zustane maly a vsecko,co jde jako modul, necht je jako modul, ono si to jadro nejak probere :o). Kazdy, kdo si kompiluje vlastni jadro (namiru), vsak initrd nepotrebuje.

[Zdenek]

Nojo, jenze kdyz je neco jako modul, tak to potrebuju ruznejma hackama inicializovat, takze hafo skriptu a neprehlednejch konfiguraku a userspace binarek, sprava zavislosti a pomalej boot, studeny parky, teply pivo a dalsi osklive veci.

[trekker.dk]

Na druhou stranu, když je něco zakompilované do jádra, tak tomu už nemůžete zadat žádné parametry, což je někdy potřeba.

[taif]

Tak to zas neni tak uplne pravda,od ceho tu mame /proc/sys ;o)

[Marcel Šebek]

Stačí předat jádru parametr ve formátu modulename.option (u 2.6).

[taif]

Jaky hacky :)?Ja myslel,ze rozhrani pro moduly je pevne dany ... a ze 2.6.x je uz ma celkem vymakany. Mno pomalej boot ... pokud nebotujes 5x denne, tak te tech par sekund, co zkonzumuje mprobe, prece nemuze rozhodim. Ja osobne povazuji moduly v linuxu za skvelou vychytavku a co jde, kompiluji jako modul.

[Zdenek]

Modprobe vcelku jde, ale depmod -a je obcas na odchod do sprchy. Netusim k cemu je, a tak na to radsi moc nehrabu. A konfigurace je slozita jak mlaticka, viz "find /etc/mod* -type f".

Je to podobnej hokej jako X11- desitky konfiguraku, nektere se edituji rucne, nektere se generuji automaticky (cti: casto jsou neaktualni a neco proto nefunguje)..

Jo a nejvic me dojima ze moduly pro char/block devices se "zavadeji" uzasne explanatory prikazem "alias" :) Proste jak ma neco 26 konfiguracnich souboru, tak to logicky nemuze byt "dobra vec tm".

[Zdenek]

Ale ten initrd musite nacpat na FDD taky. Mam takovej pocit ze syslinux umi jednak "poskladat" initrd z vice souboru (disket?), a to same zrejme bude umet i pro bzimage- takze neni problem bootovat kernel vetsi nez je velikost floppy (pripadne tak syslinux upravit).

Debianske boot floppies nemaji (nemely) zadny initrd, jen root disk, a 4 diskety s modulama se nahravaly normalne do ramdisku.

[janosh]

Výbornej článek na něco takovýho sem už dlouho čekal .

[mess]

taky si myslim, pockam si na dalsi dily

[Jan Odvárko]

Díky za článek, pomohl mi.