Vlastní kernel a šifrování disku / hibernace / .. (diskuse)

[Ondrej 'SanTiago' Zajicek]

Odkud se vlastne v pripade rootu na LVM ten kernel a initramfs natahuje? Je tam tradicni partition table a separatni /boot partition pro kernel a zavadec? Pokud ano, nebylo by cistsi se vykaslat na initramfs, nabootovat s boot partition jako rootem, z ni aktivovat LVM a pak provest pivot_root na skutecnou root partition (a remountovat boot partition do /boot)? Nebo je /boot samostatny logical volume v ramci LVM? Pak by byl asi samostatny initramfs nevyhnutelny.

[Jiří J.]

V mém případě je to typicky /boot na partišně zvlášť, ale mělo by to stejným způsobem fungovat i s LVM LV, pokud se dané LV nepohne. Jasně, mít druhý root pro aktivaci LVM/crypto/... by samozřejmě šlo, ale:

• mohly by nastat problémy při probuzení z hibernace
• moc bych si nepomohl - obsah by byl víceméně stejný, jen by nebyl zabalen do cpio+gz ... a nemusel bych mít v kernelu podporu pro initrd/initramfs, za cenu bordelu v /boot (nebo nutnosti vytvářet partišnu zvlášť)

[Miriam]

Máš moc pěknej blog, fešáčku. Měli by ti okamžitě lupnout tučnáčka. Vlastně se divím, že ti ho ještě nedali.

[petr_p]

To funguje jen do té doby, než jádro nainicializuje bloková zařízení v jiném pořadí. Proto se autor páral s blockid.

Kdyby parametr root přijímal topologické cesty (něco jako cesta v sysfs), tak by ani blockid nebylo (kromě lokálního SCSI a rootu na síti) třeba. V systémech s IDE jsou cesty statické, protože řadič má pevnou topologii (primární/sekundární kanál, master/slave zařízení). Zrovna tak SATA má jednotlivé linky staticky číslované. USB to samé.

[Kvakor]

Je pravda, že initram<něco> je třeba, pokud je rootfs šifrovaný a/nebo na LVM/RAIDu/síti/jánevímkdeještě, ale pro hibernaci to neplatí, u té stačí jen natvrdo zakompilovat do jádra partition, na které se ukládá image (volba *configu Power management and ACPI options/Default resume partition, aneb option CONFIG_PM_STD_PARTITION) plus příslušné ovladače k disku, na kterém se nachází. Pokud je v PC jeden disk s jedním swapem, stačí nastavit příslušnou partition. Pokud ne, bude to fungovat jen tehdy, když jádro při startu nadetekuje disky pokaždé ve stejném pořadí.

[Jiří J.]

Ano, je pravda, že pro probuzení z hibernace není vůbec initramfs potřeba, pokud je vše na oddílech, které umí rozpoznat kernel. Z Documentation/power/swsusp.txt:

. The resume process checks for the presence of the resume device,
if found, it then checks the contents for the hibernation image signature.
If both are found, it resumes the hibernation image.

. The resume process may be triggered in two ways:
  1) During lateinit:  If resume=/dev/your_swap_partition is specified on
     the kernel command line, lateinit runs the resume process.  If the
     resume device has not been probed yet, the resume process fails and
     bootup continues.
  2) Manually from an initrd or initramfs:  May be run from
     the init script by using the /sys/power/resume file.  It is vital
     that this be done prior to remounting any filesystems (even as
     read-only) otherwise data may be corrupted.

Jenomže já už dříve měl šifrovaný home, který jsem odšifrovával až po přihlášení pomocí speciálního skriptu, který jsem měl místo shellu v /etc/passwd, takže nešifrovaný swap se všemi klíči na disku tak nějak nepřipadal v úvahu.

Každopádně díky za poznámku, možná se bude hodit ostatním.

[Max]

Osobně proti initrd nic nemám, beru jej jako čisté systémové řešení. Jestli je boot o 1s pomalejší mně netrápí, pc uspávám. Je pravda, že se to někde může hodit. Stejně tak jsem už před několika lety přestal řešit vlastní kernel, jednoduše vše funguje a tak netřeba řešit, ba naopak, člověk by musel vždy něco dokompilovávat (virtualbox moduly, grafiku apod.). Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam. Každopádně pěkné počtení, mé díky autorovi.
Zdar Max

[Bedňa]

Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam.

Už pred rokmi vyselo na kernel.org, "nebojte sa skompilovať si svoje jadro, je to sranda" a môžem to potvrdiť, predsa o tú nám ide v prvom rade

Kompilácia má dnes význam na embedded systémoch, kde sa po zapnutí vyžaduje okamžitý štart, na desktope to už fakt nemá veľké opodstatnenie, ale že zábava to fakt je.

[-ff-]

"nebojte sa skompilovať si svoje jadro, je to sranda"

Není to sranda. Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce. Kompilace kernelu je pro takové stroje dlouhá a silně zatěžující záležitost.

[Bedňa]

Kompilácia sa dá spustiť na pozadiť s nízkou prioritou. O srandu ide hlavne v tom ako sa to dá pekne osekať až do stavu kedy to nebootne

[Josef Kufner]

Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce.

Není to na reklamaci?

[pavlix]

Kdybys měl reklamovat všechno, co vykazuje znaky šmejdu, tak můžeš reklamování zasvětit celý svůj život ;).

[Kvakor]

Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce.

Já to řeším podtaktováním, sice se úměrně prodlouží doba kompilace, ale vyhne se tím přehřátí. Pokud nejde podtaktovat, je tu ještě možnost čas od času kopmpilaci pozastavit (např. ScrollLockem na konzoli, posíláním SIGSTOP/SIGCOND a pod.), dokud se zase stroj nevychladí.

[Jiří J.]

Čistě mimochodem - na noteboocích s i3/i5/i7 procesory hodně pomáhá vypnutí turbo boost (Thinkpad X220, z 97C na 86C), na kernelu 3.9+ (kde je nový pstate driver) stačí prostě:

echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

[pavlix]

Když ten pstate driver nemám, tak se to chová jako zapnuté nebo vypnuté?

[Jiří J.]

Zapnuté, samozřejmě, je to featura na zrychlení jednovláknových aplikací. Dá se to vypnout i jinak, pokud to nejde v BIOSu (na desktopech jde, na serverech často taky, na laptopech málokdy). Docela mě to dostávalo, když jsem undervoltovával C2D (tehdy se tomu říkalo IDA). Možná by se taky mohla hodit utilitka turbostat, která je někde v tools/ ve zdrojácích kernelu.

[Jiří J.]

Jelikož se tak trochu pohybuji na hranici "HiFi", tak narážím často na USB zařízení, která mají problémy s drivery. Ať už to kvůli nekompetenci zařízení (nutnost přidat quirk do alsy) nebo kvůli hroznému stavu TT schedulingu u EHCI driveru, který Alan Stern připomíná u každého revertu / regresního fixu:

    This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
    (USB: EHCI: fix bug in scheduling periodic split transfers).  The
    commit was valid -- it fixed a real bug -- but the periodic scheduler
    in ehci-hcd is in such bad shape (especially the part that handles
    split transactions) that fixing one bug is very likely to cause
    another to surface.  That's what happened in this case; the result was
    choppy and noisy playback on certain 24-bit audio devices.

    The only real fix will be to rewrite this entire section of code.  My
    next project...

Možná se jednou dočkáme přepisu EHCI driveru, možná to brzo bude jedno (XHCI) / zařízení používající USB2.0 High Speed, možná začnou výrobci HW následovat standardy, možná dostanu hodinky s vodotryskem. Alespoň to poslední začíná pomalu vypadat reálně.

Kromě toho mám pár commitů, které udržuji čistě kvůli pohodlí - jako ochrana proti zamknutí cdrom mechaniky, změna "Disabling IRQ" na KERN_WARNING, aby mi nvidia driver nespamoval konzole, apod.

Obecně ale i u mě platí to, že tam, kde stačí distribuční kernel, nekompiluji vlastní.

[Jendа]

Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam.

Já teda taky používám distribuční, ale dokážu si představit, že budu potřebovat vlastní. Třeba kdybych ladil drivery, používal nějaké security patche jako grsec nebo chtěl mrkva.ko, kterej se asi do upstreamu jen tak nedostane :).