Sziasztok!
Arra kérek ötleteket, hogyan debugoljak egy live Linuxot. Összeraktam egy Fedora 20 live-ot, rendesen boot-ol, működik is egy darabig, aztán merevre fagy, ki tudja, mikor. Nem tudom, mi triggereli a fagyást. Egér kurzor sem mozdul. Igazából azt sem tudom, hogy X vagy kernel, talán ez utóbbi.
Hogyan debugolnátok?
Vannak persze elméleti hiányosságaim is. A filerendszer squashfs, ez ugye tömörített, read only. Ennek a belsejében lenne egy ext4? Az sem tiszta igazából, hogy file módosításkor mi történik. Valahogyan tárolja RAM-ban a read only és a módosítás közti differenciát? Akár úgy, hogy az egész módosított file RAM-ba kerül, s ezt valahol nyilvántartja? Mennyi ez a RAM, mikor fogy el?
Elfelejtettem írni: különböző hardware-eken ugyanaz a jelenség.
Update:
Megnéztem, hogyan próbálná szinte az egész operációs rendszert uninstallálni függőségként, amikor az nVidia driver uninstallját mondom neki. Úgy tűnt, a mesa-libEGL.so.1 library-n keresztül jött volna szinte minden. Az történhetett, hogy ezt a könyvtárat nem a disztribúcióból, hanem az nVidia driver részeként tette fel.
Azt csináltam, hogy a telepítendő csomagok közé felvettem a mesa-libEGL nevűt, így már nem akarta mindenáron feltelepíteni az nVidia driver-t, amelyre semmi szükségem.
Ezen felül a /var/log, /var/cache, /var/lib és még néhány alkönyvtárat tmpfs-re tettem, elkerülve, hogy az iso9660-ban lévő squashfs-ben lévő ext4 snapshot és a valóság közti differenciát tároló default 500 MB RAM hamar megteljen, s ezáltal a működő oprendszer alatt a filerendszer sérült legyen.
Hosszabb teszt csak ezután. Minden okom megvan a bizakodásra. :)
- 3916 megtekintés
Hozzászólások
Igénytelen megoldásként megpróbálnám QEMU-ban futtatni, hozzácsapott debuggerrel.
Persze az nem fog fagyni, mert így szokott az lenni :-)
- A hozzászóláshoz be kell jelentkezni
Műszaki dolgok vonatkozásában elég merész arról beszélni, mi az, amit érzek, sejtek, jó lenne utána járni.
Arra gondolok, hogy mivel a Fedora 20 még nem jelent meg hivatalosan, bizonyos logokat debug módban hagyhattak, s túl sok lesz esetleg a log, ami nyilván RAM-ban fog helyet kapni. Idővel a RAM erre a célra fenntartott része esetleg elfogy, s itt vége mindennek. Persze, ezt az érzésemet semmivel sem tudom igazolni, továbbá lehet, köszönő viszonyban sincs a valósággal.
Nem írtam, de most mondom, rendesen telepítve stabil a Fedora 20. Azt hagyjuk, hogy még ki sem jött, ugyanaz a 3.11.9-es kernele van, mint a Fedora 18-nak és 19-nek.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ezt olvasgatom. Jó, csak kell még hozzá egy kis idő. Mountolgatom fel az image-eket, hogy lássam, tényleg a leírtak szerint vannak a dolgok.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Virtuális gépben is megdöglik?
Mert ott talán egy fokkal könnyebb dolgod lenne.
Lehet, hogy hülyeség, de első körben unetbootin segítségével készítenék belőle pendrive-ot, azon fenntartanék helyet maradandó adatoknak és oda irányítanám a logokat.
Plusz kernel fagyás esetére van valami spec. billentyű kombináció (lehet, hogy külön bele kell fordítani a kernelbe?), amivel gáz esetén még lehet ezt-azt, pl. sync-elni a diszkeket, így nem vesznek el a logok.
http://en.wikipedia.org/wiki/Magic_SysRq_key
- A hozzászóláshoz be kell jelentkezni
Olvasva az irodalmat, megértettem, mi történik. Nem is olyan triviális egy live rendszert jól megcsinálni.
Van egy ext4 image file egy squashfs filerendszerbe tömörítve, ez a squasfs is egy image, amely pedig egy iso9660 filerendszeren van.
Az ext4 egy snapshot, a file-ok módosításához a rendszer lefoglal alapértelmezésben 500 MB-ot a változások tárolásához. Ugyanakkor, ha egy file-t módosítunk, majd visszaírjuk az eredetire, akkor is lefoglalva marad az 500 MB-os területből a file módosított része. Ennek oka az, hogy nyilván nem kezdi vizsgálni azt az esetet, hogy éppen az eredeti állapotra változtattuk vissza a file-t. Így ez az 500 MB terület mindig csak fogy, sohasem szabadul fel belőle. A jelenség kicsit a memory leak-re hasonlít.
Egy idő után elfogy az 500 MB terület, a filerendszeren nem lehet file-t, filerendszer leírót módosítani. Lényegében olyasmi történik, mintha telepített rendszer esetében működő gép alatt tönkremenne a HDD. Sérül a filerendszer, s merevre fagy a gép.
Jelen esetben ezt az állapotot hamar elértem, mert minden szándékom ellenére teljesen feleslegesen feltelepítette az nVidia driver-t. Erre semmi szükségem, függőségként hozta valamelyik csomag.
Ezzel az a gond, hogy boot-olás közben az akmod lefordítja a kernelmodult, ezzel rengeteg file írást végez. Írja az ideiglenes filejait, a végterméket, a logokat, ez nagyon gyorsan felemészti az 500 MB-os, filerendszer módosításra fenntartott terület jelentős részét. Ezután már kevés módosítás elég volt ahhoz, hogy megteljen a terület, így széthullott a filerendszer, a gép lefagyott.
A /home-mal nincs bajom, azt RAM-ban hoztam létre egy tömörített btrfs-en. Ugyanezt kell tennem a /var esetében is. És ki kell derítsem, melyik csomag hozza magával az nvidiát, mert ez utóbbi nagyon nem kell. Arról nem beszélve, live rendszeren semmi keresnivalója a gcc-nek.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az update utáni részt érdemes olvasni annak, akit érdekel a megoldás.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni