Dotaz: kompilace kernelu

[jnovacek]

Je nějak možné udělat následující:

nainstaluji Linux a provedu jeho nastavení,

stáhnu si nejnovější kernel,

pak si chci nastavit config, ale místo toho, abych si naklikával v "make menuconfig" to co potřebuji, spustím nějaký skript, který vytvoří konfigurační soubor podle aktuální konfigurace a nic víc do jádra nepřidá? Prostě nějak osahá počítač a zjistí co je potřeba a co se může zahodit.

Potřebuji udělat co nejmenší jádro. Jenže co tam mám zaškrtnout? Pokus omyl je hodně zdlouhavé.

Předem děkuji

Odpovědi

[mrf]

Nikdy jsem o žádném automatizačním nástroji neslyšel(pokud vím).Budete muset projít tím slzavým údolím. Jinak je třeba si uvědomit že největší masa kódu jsou ovladače takže pokud si chcete ušít jádro na míru tak já postupuju tak že u obecných voleb tam natvrdo navolím (skoro) vše. samozřejmě s určitým rozmyslem! A u zařízení naopak jenom přesně podle kompu. Viz utility hardfinfo, lshw,lspci apod.. Můžete vše natvrdo nalinkovat do jádra, (jak chcete), hlavně dát podporu pro správný chipset. Jako vstupní pomůcku možná toto(?) :

http://kernel.xc.net/

mrf

[Xerces]

Jen si to projdi, když chceš optimalizovat . Hele dá se to udělat celkem jednoduše i tak, že nabootuješ distribuční modulární jádro, pomocí lsmod si zobrazíš moduly který si to načetlo, ty si poznamenáš, pak vezmeš ten distribuční konfig a ořežeš to jenom na ty moduly který sis vypsal. Já se teda ještě zbavuju initramfs tím, že všechny moduly pro filesystémy který používám nekompiluju jako moduly ale přímo do jádra.

[filbar]

Jádro 2.6.31 by to už mělo umět pomocí volby make localmodconfig

[Michal Kubeček]

Jen je potřeba mít na paměti, že pak budou chybět některé drivery, které jsou sice potřeba, ale zatím nebyly, takže ještě nejsou natažené. Napadají mne třeba USB Mass Storage, ISO9660, vfat a další, které se týkají výměnných zařízení nebo síťových filesystémů.

[oroborus]

ak si stahnes a rozbalis nove jadro a zapnes konfiguraciu pomocou make menuconfig, novy .config sa vytvori na zaklade .config v /boot prave beziaceho jadra

[faha]

A to je fakt nebo jen domenka? Co kdyz tam mam tech jader/configu vicero? Ja tedy vetsinou config kopiruji a nasledne upgravuji.

[Michal Kubeček]

Pokud je to povoleno v konfiguraci, obsahuje jádro informaci o své konfiguraci. Tu lze získat buď skriptem, který je u zdrojáků jádra, nebo (opět je-li to povoleno) v /proc/config.gz. Jestliže běžící jádro poskytuje svou konfiguraci a neexistuje ještě .config, vezme se jako výchozí právě konfigurace právě běžícího jádra.

[faha]

pekne, o tom uchovani cfg v jadre jsem neco cetl, ale napr. debian (etch i lenny) tohle v distribucnich jadrech nemaji, take jsem to nenasel na centos/redhat, jedine kde to vidim je starsi madriva (2006). diky za info.

[Michal Kubeček]

Distribuční jádra OpenSuSE mají nejen konfiguraci v jádře, ale i /proc/config.gz

[jnovacek]

Toto jsem vyzkoušel, ale s tímto konfigurákem systém nenajede.

[rastos]

Toto jsem vyzkoušel, ale s tímto konfigurákem systém nenajede.

Kvôli čomu? Zbuilduješ a nainštaluješ aj moduly?

[jnovacek]

Prvně jsem to jenom překopíroval - to nejelo. Pak jsem vyzlouše zmiňované make localmodconfig a make localyesconfig a je to.

Jádro má 6MB a nic víc nepotřebuje.

[michich]

V RHEL a CentOS je konfigurace kernelu jako soubor součástí rpm balíčku (/boot/config-$verze).

[oroborus]

>to je fakt.

debian:/usr/src/linux-2.6.32.3# make menuconfig
scripts/kconfig/mconf arch/x86/Kconfig
#
# using defaults found in /boot/config-2.6.32.3
#

*** End of Linux kernel configuration.
*** Execute 'make' to build the kernel or try 'make help'.

(zhodov okolnosti som spustil konfiguraciu jadra, prave tej verzie, ktora mi prave bezi,
keby som mal pustene jadro 2.6.31 a dal by som kompilovat jadro 2.6.32, tak by sa novy
config jadra 2.6.32 vytvoril na zaklade configu 2.6.31)

>Co kdyz tam mam tech jader/configu vicero?
Tak sa pouzije config, prave beziaceho jadra najdeny v /boot/

[SKooDA]

Gentoo má genkernel, tak bude určitě existovat něco podobného, nebo skus použít přímo ten z gentoo, v podstatě by to mělo akorat podle lspci a dalších věcí osahat hw. -

[ext3fs]

Tohle ale imho resi jen drivery, ale nemuze to vyresit nic okolo site (tun/tap, netfilter, IPv4/6,..atd), ACPI (mozna castecne), a vubec takove to rucni doladeni jadra (General setup, File systems, USB Support,...) Takze osobne si myslim, ze podobne automatizacni utility nemuzou nikdy poradne fungovat a nebo funguji jen na takove urovni, ze neprinesou temer zadny prinos v porovnani s distribucnim jadrem.

[pht]

Od 2.6.31 existuje make localyesconfig a make localmodconfig. To první je lepší, protože to ovladače zakompiluje natvrdo do jádra a nemusíte řešit initramfs. Stejně ale budete muset v menuconfigu výsledek projít, protože distribuční jádra mají zapnuto téměř všechno co lze zapnout, navíc některé volby ve vícepoložkových seznamech Vám nemusí sedět na míru (typ procesoru, preempce, ...).

Já osobně to na nových strojích dělám tak, že použiju make defconfig, a pak projdu položku po položce menuconfigem. Jiná cesta ke správnému nastavení jádra, než se naučit co která volba znamená, bohužel není Ale výsledek se dostaví poměrně brzo.

Jo a použít distribuční config z /boot nebo z /proc nemá cenu protože tam právě bude všechno zaškrtnuté.

[Michal Kubeček]

…protože to ovladače zakompiluje natvrdo do jádra a nemusíte řešit initramfs.

To už dnes taková výhra není, protože initial ramdisk se hodí i z mnoha jiných důvodů.

[pht]

Např. ?

[Michal Kubeček]

Kořenový filesystém na LVM nebo softwarovém RAIDu, zajištění persistentního jména pro zařízení s kořenovým filesystémem (udev), kontrola kořenového filesystému ještě předtím, než se přimountuje, …

[pht]

To bych nazval spíše okrajovými podmínkami. Mám zkušenost, že většina lidí, co si kompiluje kernel kvůli optimalizaci, se tímto nechce zabývat, takže neřeší ani initramfs. Ale samozřejmě proti gustu žádný dišputát.

[trekker.dk]

Kořenový filesystém na LVM nebo softwarovém RAIDu

SW RAID není bez initramfs problém. Co mám zkušenost, je s tím dokonce míň problémů.

[Michal Kubeček]

SW RAID jako takový ano. Ale má-li na něm být kořenový filesystém, je potřeba ho před jeho přimountováním inicializovat.

[trekker.dk]

Můj příspěvek platí i pro případ, kdy je kořenový fs na SW RAIDu. (Tohoto případu se také týká - alespoń podle mých zkušeností - ta část "méně problémů")

[Michal Kubeček]

S využitím autodetekce RAIDů jádrem by to asi šlo, ale ta je nešťastná sama o sobě, proti tomu mi přijde initial ramdisk menší zlo. Pokud se tedy o něm dá vůbec mluvit jako o "zlu".

[trekker.dk]

S využitím autodetekce RAIDů jádrem by to asi šlo

...asi to používám na třech strojích. Jediný problém se objevil, když se změnilo pořadí mezi autodetekcí RAIDu a detekcí swapovacího oddílu, ze kterého se má probouzet TuxOnIce - probouzení ze swapu na MD přestalo fungovat, protože v době detekce swapu oddíl ještě neexistoval.

ale ta je nešťastná sama o sobě

Nevidím, co je na tom nešťastného. Starat se o SW RAID má na starosti jádro, tak ať se taky stará o to ho sestavit. Nevidím důvod, proč k tomu vyžadovat nástroj v userspace.

Pokud se tedy o něm dá vůbec mluvit jako o "zlu".

- zapomeneš sestavit nový při aktualizaci jádra - nenabootuješ (a to šlo o update mezi 2.6.32.2 a 2.6.32.4, přesto nešel načíst ovladač pro raid)

- chybně sestavíš startovací skripty a následně použiješ probouzení - sbohem, data

A zatím ještě nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.

[Michal Kubeček]

Jediný problém se objevil, když se změnilo pořadí mezi autodetekcí RAIDu a detekcí swapovacího oddílu, ze kterého se má probouzet TuxOnIce - probouzení ze swapu na MD přestalo fungovat, protože v době detekce swapu oddíl ještě neexistoval.

To je právě jeden z problémů - nemožnost ovlivnit, kdy přesně se bude RAID inicializovat (co musí být předtím a co musí být až potom). Další potenciální zdroj problémů nastane v okamžiku, kdy se zboří systém a budu ten RAID potřebovat připojit k jinému počítači, abych z něj dostal data. Nebo dojde k poškození dat a já budu potřebovat, aby se RAID automaticky nenastartoval a nezačal syncovat, protože tím by data definitivně pohřbil.

Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků. Funguje i potom jaderná autodetekce?

Starat se o SW RAID má na starosti jádro, tak ať se taky stará o to ho sestavit. Nevidím důvod, proč k tomu vyžadovat nástroj v userspace.

Např. mi to umožní ovlivnit, jestli se má opravdu sestavit a kdy se to má stát. Síťová komunikace (po transportní vrstvu) je také realizována jádrem, ale konfiguruje se userspace nástrojem.

A zatím ještě nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.

Co ty dva příklady, které jsem uváděl výše - kořenový filesystém na LVM a persistence jména zařízení (modelový příklad: počítač má pouze dva disky připojené přes USB a kořenový filesystém je na jednom z nich). Případně mne napadá ještě šifrovaný kořenový filesystém nebo bezdiskové stanice bootující po síti.

[pht]

Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků. Funguje i potom jaderná autodetekce?

IMHO ano, protože disk bez oddílů se jeví v Linuxu obecně jako jeden oddíl.

[Michal Kubeček]

IMHO ano, protože disk bez oddílů se jeví v Linuxu obecně jako jeden oddíl.

Nic takového jsem nikdy nepozoroval, pořád platí, že nerozdělenému disku odpovídá zařízení (např.) /dev/sda (s minor číslem dělitelným šestnácti), zatímco oddílu /dev/sdan, kde n je (nenulový) zbytek minor čísla při dělení šestnácti.

[pht]

seeing is believing

md: md0 stopped.
md: bind<hdd>
md: bind<sda1>
md: bind<hde1>
md: bind<hdf>
raid5: device hdf operational as raid disk 0
raid5: device hde1 operational as raid disk 3
raid5: device sda1 operational as raid disk 2
raid5: device hdd operational as raid disk 1
raid5: allocated 4208kB for md0
raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
 --- rd:4 wd:4
 disk 0, o:1, dev:hdf
 disk 1, o:1, dev:hdd
 disk 2, o:1, dev:sda1
 disk 3, o:1, dev:hde1
 md0: unknown partition table
XFS mounting filesystem dm-0
Starting XFS recovery on filesystem: dm-0 (logdev: internal)
Ending XFS recovery on filesystem: dm-0 (logdev: internal)

(ano, to je auto config)

[Michal Kubeček]

Fajn, ale to pořád ještě ani zdaleka neznamená, že "disk bez oddílů se jeví v Linuxu obecně jako jeden oddíl", jen že si s tím autodetekce v jádře poradí. Akorát by mne zajímalo, kam až jádro ve snaze najít superbloky jde, tj. u jakých všech blokových zařízení to zkouší. Zvládne třeba RAID z RAIDů?

[trekker.dk]

Nebo dojde k poškození dat a já budu potřebovat, aby se RAID automaticky nenastartoval a nezačal syncovat, protože tím by data definitivně pohřbil.

Ne že bych za to byl ochoten dát ruku do ohně, ale mám ten dojem, že sestavené pole je označené jako active(auto-read-only) a to do té doby, než na to pole něco zapíše (a teprve pak se začne syncovat)

Ale i tak - když si nebudu jistý, tak tam buď můžu disky strkat po jednom a kopírovat z nich data pryč, nebo je připojím až po nastartování systému (pokud jsou SATA)

Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků.

Přiznávám se, že nevím, nikdy by mě nenapadlo něco takového udělat.

Síťová komunikace (po transportní vrstvu) je také realizována jádrem, ale konfiguruje se userspace nástrojem.

I v případě, že se bootuje ze sítě? Konfigurační volba nazvaná "kernel level autoconfiguration" naznačuje, že tvoje tvrzení není vždy pravdivé. (Mj. je to reakce i na druhou polovinu poslední věty tvého příspěvku.)

Takže v případě, že jádro ví, co chci udělat (nahodit síť, použít DHCP, nabootovat), může klidně nakonfigurovat síť bez userspace. To samé, když jádro ví, co chci udělat (nahodit MD pole a připravit je k práci), může to udělat taky.

K poslednímu odstavci - jak jsem psal, ještě jsem nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.

[Michal Kubeček]

I v případě, že se bootuje ze sítě? Konfigurační volba nazvaná "kernel level autoconfiguration" naznačuje, že tvoje tvrzení není vždy pravdivé. (Mj. je to reakce i na druhou polovinu poslední věty tvého příspěvku.)

Při "normálním" bootování ze sítě není důvod, aby to dělalo jádro. Prvotní nastavení a první fázi bootu provede BIOS (jádro těžko, tohle se musí udělat dřív, než se jádro vůbec stáhne). Podruhé už to klidně může provést userspace a má to i tu výhodu, že je to konfigurovatelné. To, co popisujete, se používá pouze v jednom specifickém případě (nfsroot) a i tam to lze řešit jinak - právě díky initial ramdisku.

Další příklad je třeba IPsec: protokoly ESP a AH jsou implementovány jádrem, ale nastavení SAD nebo SPD se provádí z userspace, buď ručně příkazem setkey, nebo to dělá automaticky racoon podle toho, co si dohodne s protistranou. Nebo třeba netfilter, také je realizování jádrem, ale konfiguruje ho userspace.

[trekker.dk]

No, abych tuhle debatu, která stejně nikam nepovede, ze své strany uzavřel - mě initramfs přidává víc práce, než mi šetří, takže ho nepoužívám a nebudu ho používat dál, dokud nebudu muset.

Někdo to dělá jinak, jeho věc.