Jak jsem si naběhl s Linux MD RAID a LVM (diskuse)

[Honza Jaroš]

Že by to fakt na holém disku bez partition typu fd nejelo...?

[CET]

Taky mi to tak pripada. A zaroven tak trosku to nakousnul petr_p.

Kdyz se RAID startuje z jadra, tak linux hleda oddily fd(autoraid). Protoze tak jsou nastaveni partisny na sd[abc], tak to tak vypada, ze se to pouziva. Tady je teda zrejme chyba v tom, ze ty disky sd[def] linux nepoznal jako raid a nevytvoril z toho ten /dev/md2.

Pokud by se to nahazovalo z initrd pomoci mdadm, tak jsem nezaznamenal aktualizaci configu /etc/mdadm.conf v initrd.

Co presne mysli petr_p tim initramfs, to nechapu.

V obou prvnich pripadech se ale nenahodil /dev/md2, a protoze chybel PV ve VG, tak se nenahodil ani VolumeGroup a cili nejsou ani logicky disky.

Protoze se jeste LV nezvetsily, IMHO by mohlo stacit odebrat PV /dev/md2 z VG a melo by to pri dalsim rebootu nabehnout. Pripadne bootnout nejakej LiveCD, nahodit /dev/md2 a VG rucne a vyresit to.

[kamiln]

Dekuji, ze jste mi to objasnil, kdyz uz to autor neudelal. Mel jsem podobny problem a pomoci vasi rady aktualizovat initrd se mi podarilo ho vyresit.

[petr_p]

Dedukuji, že rootfs je na /dev/md0. Pak ale chybí zásadní informace, jestli se používá jaderná autodetekce raidu (jedna zastaralá a nedoporučovaná věc), nebo jestli se to staví ručně přes initrd (další zastaralá nedoporučovaná věc) nebo přes initramfs (jediná správné řešení), a v druhém/třetím případě, jak vypadají startovací skripty (které disky jsou zapojeny do scanu, jestli se pole identifikuje pres UUID atd.).

A ještě tu může být trapná chyba se zpřeházenými názvy disků, kdy jste si přepsal běžící systém.

[prOm3TheuS]

Co je na jaderné autodetekci raidu špatného? Docela by mně to zajímalo - rád se přiučím něčemu novému. Initrd je dneska už opravdu staré a initramfs používám pouze v případě, kdy není schopen kernel získat informace o raidu právě tou autodetekci.

[petr_p]

RAID Boot - Linux-raid:

This approach can cause problems in several situations (imagine moving part of an old array onto another machine before wiping and repurposing it: reboot and watch in horror as the piece of dead array gets assembled as part of the running RAID array, ruining it); kernel autodetect is correspondingly deprecated.

Pak jsem ještě něco zahlédnul v jaderné dokumentaci.

[CET]

Co presne myslis rozdilem mezi initrd a initramfs?

[prOm3TheuS]

Co já vím, tak initramfs je soubor utvořený jako blokové zařízení (prostě image virtuálního disku), namísto initramfs je vlastně zabalený cpio archiv, který se při bootu rozbaluje do paměti tmpfs. S initramfs se pak dají dělat docela pěkná kouzla, jako že se třeba automaticky při kompilaci jádra do něj zaintegruje. Jádro má pak třeba 10 MB, ale už se pak neumsí dávat do zavaděče položka initrd. Navíc initramfs je vlastně dokonalejším nástupcem initrd a tak se dá initrd považovat za zastaralý.

[prOm3TheuS]

Jsem přesně čekal, že se do toho zamotám, hned z prvu má být "co já vím, tak initrd je soubor..."

[CET]

no, z grubu se oboje nahrava jako initrd - jestli se da zaintegrovat initramfs do jadra, pak je to docela dobra featurka, nadruhou stranu se mi zda docela lepsi, ze pouze pregeneruju initrd image (at uz je to image na loopu nebo cpio), ale nemusim menit kernel. Oboje je ale nejaky maly system, ktery nastartuje zakladni veci a pak spusti hlavni init na pripojenem skutecnem root device. Takze si nejsem jistej, jaky by byl rozdil nahazovani RAID z initrd nebo z initramfs. V obojim by se to startoval zrejme pomoci mdadm a pak se nahodi VG a LV, pripoji a privot_rootem spusti system, nebo ne?

[prOm3TheuS]

Naprosto žádnej. Uvnitř to funguje úplně stejně akorát rozdíl jse v tom, jestli je to image a nebo cpio archiv. Jedinej rozdíl je v tom, že do kódu initrd už nikdy nikdo nehrábne a vyvíjet se bude pouze initramfs. Je tam ještě jeden limit a to, že u initrd je limit snad 4 nebo 5 MB. U initramfs je tím limitem velikost RAMky.

[CET]

No, ja mel na mysli prave ten rozdil pri spousteni. A ten neni zadnej. Proste se nahraje do pameti, pripravi, spusti linuxrc, pripravi root system, prepne do nej a spusti init. At v initrd nebo v initramfs.

[petr_p]

Mezi initrd a initramfs je výrazný rozdíl z hlediska toho, jak je to uděláno v jádře. V podstatě initramfs je integrální částí jádra a i když jej vědomě nepoužíváte, tak tam stále je (reliktem je záznam /dev/rootfs v /proc/mounts). Initramfs se nekopíruje dva krát (rychlejší boot), nespouští se z něj /linuxrc, ale /sbin/init, změna rootfs se už neprovádí přes chroot+pivot_root, ale přes switchroot (v podstatě smazání obsahu initramfs, chroot a exec těžkého /sbin/init), initramfs už nelze odmountovat.

Z hlediska správy je výhoda, že je to součástí obrazu jádra, takže řešíte jediný soubor. Taktéž výroba tohoto cpio archivu je v režii přímo kompilačního skriptu jádra, takže stačí make v /usr/src/linux a je to. Tím že se to vyrábí spolu s jádrem, tak máte jistotu, že se vám nebudou bít různé verze udevu busyboxu aj. s jaderným API.

Přečtete si k tomu jadernou dokumentaci k initramfs (je to tam pěkně popsáno).

Z hlediska sestavování diskového pole ten rozdíl proti initrd není. To jsem chtěl jen autora popíchnout, aby přestal používat zastaralé postupy.

[Josef Kufner]

No ono jestli přebalit archiv nebo znovu slinkovat jadro mi už moc veliký rozdíl nepřijde. Možná to druhé bude trvat o nějakou tu sekundu víc. Ale mít to slinkované dohromady může být obrovskou výhodou při bootování ze sítě nebo při bootování z nějakých obskurních zařízení. Na druhou stranu, pro zabalení archivu není potřeba mít na disku rozkompilované zdrojáky...

[CET]

Pro me je o hodne jednodussi

zcat ../initrd | cpio -i
## make changes here
find | cpio -o | gzip > ../initrd

[kamiln]

To by mě opravdu zajímalo, proč k tomu došlo. Kdy se dočkáme toho slíbeného pokračování?