Portál AbcLinuxu, 25. dubna 2024 19:52
. 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.
make localmodconfig
13.1.2010 16:06
/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.
/proc/config.gz
Toto jsem vyzkoušel, ale s tímto konfigurákem systém nenajede.Kvôli čomu? Zbuilduješ a nainštaluješ aj moduly?
make localmodconfig a make localyesconfig a je to.
Jádro má 6MB a nic víc nepotřebuje.
14.1.2010 10:30
michich | skóre: 51
| blog: ohrivane_parky
/boot/config-$verze).
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é.
…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ů.
Kořenový filesystém na LVM nebo softwarovém RAIDuSW RAID není bez initramfs problém. Co mám zkušenost, je s tím dokonce míň problémů.
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.
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.
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.
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.
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)
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.
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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.