Először is nyugtassatok meg, hogy van ez a boot folyamat dolog annyira érdekes, hogy rászánhatom az időmet! Köszi... :-)

Ma végre volt kis időm, és megnézegettem, hogyan is dolgoznak a törpék az Ubuntu initramfs csodájában. Konklúzió: way fuckin' too much complicated, és itt még tudnék pár jelzőt írni. Főleg azok után, hogy szépen összehasonlítottam az Eee PC hasonló megoldásával. Talán ha ezeknek a mini fájlrendszereknek a méretét leírom, Ti is össze tudjátok gyorsan hasonlítani:

EeePC 1,2kbyte vs. Ubuntu 22,6 Mbyte (!), azaz 20x-os az Ubuntu túlsúlya.

Természetesen igazságtalan vagyok, hiszen az Eee hardvere minden esetben ugyanaz, ezért nem kell felkészülni mindenféle váratlan helyzetre, az Ubuntu pedig egy általános célú operációs rendszer. De nem csak sok drivert pakoltak az Ubuntuba, hanem lehetetlen módon el is bonyolították a dolgot! "Mint az közismert", az initramfs gyökerében lévő init szkript indul el először, és az futtat le mindenfélét.

Szokásos keretes írásom arról fog szólni, hogy hogyan lehet belekukkantani saját initrd-nk belsejébe. Keresgéljünk a /boot alatt! A grub menüjében (/boot/grub/menu.lst) benne van egy initrd=xxxxx sor is. Keressük meg azt a szekciót, amit jelenleg ki szoktunk választani a grub menüből (azaz a jelenleg futó kernelre vonatkozó paraméterek)! Ha nem szoktál semmit kiválasztani, akkor nagy valószínűséggel az első lesz az. :-) Szóval az a bizonyos xxxxx az initrd elérési útja és neve. Ha megvan, akkor másoljuk ki magunknak a fájlt egy kényelmes  helyre. Ez a fájl gzip-pel tömörítve van, de a gzip addig nem foglalkozik velünk, amíg nem .gz a kiterjesztés. A kapott fájl pedig egy ún. cpio archívum, amelyet ha kibontunk, megkapjuk az egész kis fájlrendszert; /bin, /lib, stb. könytárakkal. Éppen ezért nehogy véletlenül rossz helyen (könyvtárban) legyünk a kicsomagoláskor! Ha rácsomagolunk a /bin-re, az nem túl egészséges.

bagoj@aranyhal:~$ mv initrd.img-2.6.24-16-generic initrd.img-2.6.24-16-generic.gz
bagoj@aranyhal:~$ gunzip initrd.img-2.6.24-16-generic.gz
bagoj@aranyhal:~$ cpio -i < initrd.img-2.6.24-16-generic

Nincs elírás, a gunzip leszedi a .gz kiterjesztést, és az a kacsacsőr nagyon is fontos! Anélkül a cpio állni fog és várni az idők végezetéig...

Ezek után máris lehet nézegetni a nyalánkságokat. ;-)

Mi ez a mindenféle? Aki ért a bash szkripteléshez, maga is megnézheti, a többi, szerencsésebb sorsú ember számára:

1. Kell nekünk egy / fájlrendszer, amin dolgozunk. Ez most az initramfs lesz, azaz az a mini fájlrendszer, amit a keretesben kicsomagolunk.
2. Kell egy /proc, /sys és /dev, ami szükséges ahhoz, hogy az eszközöket, perifériákat, folyamatokat lássuk.
3. Fel kell dolgozni a parancssori paramétereket. Aki itt már elismerően hümmög és sejti, hogy ezek a paraméterek a grub-ban megadott boot paraméterek, az nyert egy kakasos nyalókát.
4. El kell végezni azt a bizonyos munkát a modulok betöltésével, hiszen az initrd-nek ez a legfőbb feladata.
5. Át kell mozgatni a felcsatolt partíciókat a /root alá (ahogyan az előző postban írtam), hogy az igazi init program, minden programok szülőanyja megtalálhassa.
6. Át kell adni a vezérlést az igazi initnek.

Ezt az Eee PC-ben megoldották olyan 40 sorban, az Ubuntuban több száz sornyi kóddal. Azt mindenesetre kapisgálom, hogy mi volt eddig a probléma; és ennek megfelelően AZÉRT IS ki fogom gyökölni a unionfs szkriptemet, ugyanis egyre inkább meggyőződésem, hogy nagyon jó dologba tenyereltem bele. Hiszen mostanában nagyon terjednek a memóriakártyák és SSD merevlemezek, amelyek sok írást nem bírnak ki, ezért adódik hogy védjük őket. Nem utolsó sorban végre belemélyedtem az initramfs szépségeibe is, amiktől eddig a sors megóvott...

Most már hamarosan. Addig is írjatok, hogy mennyire érdekes a téma (de az az igazság, hogy rengeteg blogot látok, amelyik linkeket gyűjt, meg olyan is van, amelyik alkalmazásokkal foglalkozik. Viszont nehéz találni, főleg magyarul ilyesféle, rendszerközeli dolgokkal foglalkozó blogot. Ezért foglalkozom most ezzel a témával).

Mai napi bónusz annak, aki idáig még nem unja: A boot felgyorsításának az is remek módja (kernel újrafordítás nélkül!), hogy kigyököljük a kernel-fordítás post alapján, hogy milyen modulok kellenek nekünk; majd felrakjuk az initramfs-tools csomagot (ez kell az initrd újragenerálásához, ezt múltkor elfelejtettem írni), majd a /etc/initramfs-tools/initramfs.conf-ban megkeressük a MODULES=most sort, és átírjuk MODULES=list-re, majd ugyanebben a könyvtárban a modules fájlba felsoroljuk, hogy mi kell nekünk. Kevésbé bátrak válasszák a MODULES=dep opciót. A "most" ugye azt jelentené, hogy a legtöbb modult betölti, a "dep" kitalálja, mire van szükségünk, a "list" pedig csak azokat tölti be, amiket mi szeretnénk. Ne felejtsétek, hogy csak azok a modulok igazán szükségesek, amikre a boot-nak szüksége van! A többi modult be tudja tölteni a kernel később is, amikor szükség van rá.

Ezek után (rootként ám!):
root@aranyhal~# update-initramfs -u
Ha valami nem jött össze, ne szigyjatok nagyon, hanem írjatok és akkor kitérek arra, hogyan mentsük meg a rendszert félhalott állapotból. :-)

 

Körülbelül 100 helyen olvasom rengeteg optimista és lelkes Linux-hívő blogjában, hogy "feltettem az új Hardy-t, de nem működik az X vagy az Y, pedig már az előzőben is majdnem működött, meg különben is, Z és K hibásan működik stb." és most jön a lényeg: "Nagy csalódás volt az egész".

Nekem egy picit érthetetlen ez a dolog, de mindjárt megvilágítom; mégpedig anélkül, hogy egyéb operációs rendszert megemlítenék. Szóval:

1. A Canonical, akármennyire is nagy támogató, kis cég a nagy szoftvergyártókhoz képest. Ebből következően, ha van is ráhatása pl. a kernel meghajtók, vagy egyes alkalmazások fejlesztésére, ez leginkább úgy történik, hogy küldenek patch-et aztán vagy felhasználják, vagy nem. Utóbbi esetben a kiadás előtt megpatkolják maguk a programokat.

2. A Canonicalnak nincs 5000 alkalmazottja csak arra, hogy a grafikus felület használhatóságát és az új ötleteit teszteltesse. Nekik programozóik vannak.

3. A világ összes hardverét összevásárolni, arra fejleszteni és letesztelni lehetetlen feladat, amire semelyik cég nem vállalkozott még eddig. Általában az a jellemző, hogy a hardverhez kapjuk a meghajtót is.

Ezek után jöhet a következtetés: A Canonical egyetlen lehetősége, hogy velünk teszteltesse le a millió programágat, hardvert és egyéb dolgokat. Ha valami nem működik, akkor ne csak a blogon siránkozzunk, hanem nyomjuk felfelé a hibajelentést. Lehet, hogy egy-egy hibajelentés nem talál nyitott fülekre mert van elég bajuk, de ha ugyanaz előfordul már ezredszer, akkor csak megcsinálják.

A 8.04 Hardy Heron LTS verzió; de ennek is kell egy kis idő, míg stabillá rázódik. Képtelenség a tökéletest elvárni, miközben a kereskedelmi szoftverek korai változatai, valamint nagy verzióváltásai hemzsegnek a különféle hibáktól. Pedig azért ugye fizetünk...

Uff. Csókol benneteket Bagoj.

Nem fogjátok elhinni, de még mindig nem a konkrét megoldás fog következni! :-)
Ugyanis közben elkezdtem egyrészt tűnődni a dolgon, és összeírtam a magam számára is, hogy pontosan milyen lépéseket kellene megtenni, meg hogy hogyan is működik pontosabban a unionfs. Úgyhogy nehogymá ne publikáljam... Persze igyekszem nem lemenni forráskód-szintre!

Amint írtam - és ahogyan a név is sugallja - könyvtárak egyesítését tudjuk elvégezni. Így aztán a unionfs-nek teljesen mindegy, hogy milyen típusú fájlrendszerek vannak az alsóbb szinteken; hiszen könyvtárakkal, nem fájlrendszerekkel foglalkozik. (Bizony, az egyik lehet CD-ROM, a másik akár NFS partíció is, így a változásokat a távoli szerver tárolja.) Ezeket a könyvtárakat branch-nek, ágnak nevezik.

Az egyesített könyvtárakat többféle módon kezelhetjük: lehet egyesíteni több csak olvasható (ro), olvasható és írható (rw), vagy ezek kombinációjából álló partíciókat. A lényeg így néz ki:
mount -t unionfs -o dirs=<első_könyvtár>:<második_könyvtár>:<harmadik könyvtár> none <célkönyvtár>A megadott könyvtárak közül az lesz a magasabb szintű, amit később adtunk meg. Azaz ha egy fájl hasonló névvel létezik kettőben (vagy akár mindegyikben), a legutolsó könyvtárban lévő fog látszani (mintha rétegek lennének egymás felett).

A fájlok létrehozásának lekezelése viszonylag egyszerű: Ha létezik a fájl a legfelső rétegen, és írható a fájlrendszer, akkor létrehozza ott. Ha nem, akkor megnézi egy szinttel lejjebb. De a létrehozott fájl, függetlenül attól, hogy hol jött végül létre, a célkönyvtárban látszani fog. A mi esetünkben itt, ahogy írtam az előző postban, egy copy-on-write történik, azaz az alsó (ro) rétegről átmásolja a felső (rw) rétegre a fájlt és kész.
A fájlok törlése viszont kicsit bonyolultabb: a törlés mindig a legalsó rétegen kezdődik. Ugyanis ha egy fájlt törlünk a célkönyvtárban, akkor alapértelmezésben hipp-hopp, várakozásainknak megfelelően eltűnik. Természetesen nem törlődhet a legalsó rétegről, hiszen az csak olvasható. Ehelyett a unionfs bejegyzi, hogy ez a fájl törölt állapotú (unionfs nyelven: whiteout). És csak akkor fog felbukkanni újra a fájl, ha újra odamásoljuk. Szerencsére nem csak ez a törlési mód van, hanem létezik olyan is, amit mi szeretnénk: törlés esetén ismét "előbukkan" az eredeti fájl a ro partícióról. Ezt a törlési módot nevezik delete_first-nek. Ez az, amit használnunk kell.

Ötlet: Ha jól vágom, a célkönyvtár megegyezhet bármelyik egyesített könyvtárral (!). Tehát, ha úgy akarunk tenni, mintha írható lenne a /media/cdrom0 könyvtárunk:
mount -t unionfs -o dirs=/home/bagoj/cdre:/media/cdrom0=ro none /media/cdrom
Megvalósítás

Ha-ha, ahogy mondani szokás, 4 egyszerű lépésben fogjuk megoldani! :-) Mivel az egészet egy kernel paraméterrel fogjuk szabályozni, először megnézzük, hogy szükséges-e bármit csinálnunk. Nyilván boot paramétert kell alkalmazni, hiszen boot időben kell eldöntenünk, hogy használjuk-e a unionfs-t, vagy pedig csak simán bootolunk (a következő snapshot előállításához). Tehát:

1. A "/" fájlrendszert át kell mozgatni a "/ro" könyvtárba, csak olvashatóra. (Nekem ez a /dev/sda3)
2. Fel kell csatolni a változásokat tartalmazó partíciót a "/rw"-be. (nekem: /dev/sda5)
3. Egyesíteni kell a "/ro"-t és "/rw"-t a "/" alatt; ez lesz a fájlrendszer
4. A "/home"-ba felcsatoljuk a home partíciót (nekem: /dev/sda6)

A boot folyamat kicsit róka fogta csuka: A / fájlrendszerrel dolgozunk, de ahhoz, hogy az egész elindulhasson, szükség van a / fájlrendszerre. Ez az, amiért initrd-t kell használnunk. Azaz, a grub-nak alapértelmezésben szépen megadjuk, hogy most unionfs-t szeretnénk. A grub betölti az initrd-ben található initramfs-t, ami egy mini fájlrendszer, amiben megtalálható a kernel, a szükséges modulok, és szkriptek is. Pontosan ide, erre a pontra fogjuk belegyártani az okosat, hiszen itt el tudjuk dönteni, hogy kell-e; rendelkezésre áll a unionfs modul amit betöltünk a memóriába, meg tudjuk lépni a fent leírt 4 lépést, majd hagyjuk, hogy az initrd-ben lévő kernel folytassa a rendszerindítást.

Első lépésben telepítsük fel a szükséges dolgokat:
bagoj@aranyhal:~$ sudo apt-get update
bagoj@aranyhal:~$ sudo apt-get install unionfs-tools
Ezután meggyártjuk a szkriptet, az Ubuntu beépített eszközével újrageneráljuk az initramfs-t, beleírjuk a grub konfigjába a szükséges paramétert és kész is. A szkripttel fogom folytatni; ha minden igaz, holnap. ;-)

Az előző post a törölt fájlok visszaállításáról igazából egy bevezető akart ám lenni! Amiről most írni akarok, arra egy kolléga hívta fel a figyelmemet, ugyanis Neki van egy Eee PC-je. Ezen a furmányos kis szerkezeten nyilvánvalóan sok orosz mérnök dolgozhatott, mivel tele van nekem tetsző apró kis trükkökkel. Ilyen példáaul a unionfs használata.

A névből kiviláglik, hogy valamiféle fájlrendszerről van szó. Mit tud ez? A segítségével logikailag egyesíteni lehet különféle (fájlrendszerbeli) könyvtárakat, eközben a fizikai tartalmukat külön lehet tartani. Praktikusan egy példán keresztül: Egy (amúgy nyilván csak olvasható, readonly = ro) CD-ROM tartalmát "összefésüljük" egy írható, merevlemezen lévő könyvtárral egy fájlrendszerbe. Kezdetben, ha a fájlrendszert nézzük, a CD-ROM tartalmát láthatjuk, de úgy, hogy az írható-olvasható (read-write = rw) - legalábbis annak látszik a unionfs miatt. Ha bármelyik fájlt átírjuk, vagy újakat hozunk létre, akkor a unionfs lemásolja a CD-ROM-ról a fájlt a merevlemezre (Copy on write = cow), és ott megcsinálja a módosítást. Tehát azokat a fájlokat, amelyeket változtattunk, már a merevlemezről olvassa fel, a változatlanokat meg a cd-romról. Következésképpen, a CD-ROM tartalmazza az eredeti változatot, a merevlemez pedig a változásokat; mi mégis úgy látjuk, mintha egyetlen fájlhalmaz lenne. Ha el akarjuk dobni valamelyik változtatást, akkor csak le kell törölni az rw könyvtárból a fájlt, és látni fogjuk a CD-ROM-on lévő ro változatát (de persze újra átírhatjuk). Ez marha jó, hiszen vissza tudjuk gördíteni az állapotot egy előző "jó" állapotra. Ha pedig úgy döntünk, hogy új "jó" állapotot (snapshot) készítünk, akkor kiírjuk egy új CD-re az egészet, a régi meg töröljük/kidobjuk.

Namost felejtsük el a CD-ROM-ot gyorsan, és helyettesítsük be egy readonly partícióval. Elértünk a cím magyarázatához: Ha nagyinak, vagy nem túl hozzáértő havernak adnánk oda egy disztribúciót, esetleg pl. egy iskolába gyártunk desktop gépeket, amelyeken a változtatásokat szeretnénk minden nap egy mozdulattal ledúrni, akkor megtehetjük így. És persze ha CD-ről vagy USB penről bootoló rendszert gyártunk, akkor is hasznos lehet (utóbbi esetben azért, mert az USB penek olcsók, ezért sok embernek eszébe jut egy hordozható linux telepítése, amit bedug bármelyik gépbe és megy. Csakhogy ezek az USB-s memóriák nem arra vannak ám tervezve! Kibírnak mondjuk 100,000 írást, aztán kuka. És egy oprendszer sűrűn írogat ám...), RAMdisk-kel karöltve (azaz a rendszer ro, a változtatások a memóriában tárolódnak, kikapcsolásig - tipikus live cd viselkedés).

És ha mégis változtatásra lenne szükség, hát semmi gond; fel lehet mountolni rw-be a rendszerpartíciót, megtenni a változtatásokat, ezzel új "snapshot"-ot hozva létre. A snapshotok között a user meg hadd tomboljon...

Hála az Ubuntusoknak, sajnos a unionfs, illetve a későbbiekben bemutatandó aufs is initrd-n keresztül érhető el kényelmesen. Ez azt jelenti, hogy ha gyári kernelt használunk, akkor az apt-get-tel lehúzzuk a támogatást és kész. Ha saját kernelünk van, akkor előbb meg kell patch-elni a unionfs vagy aufs oldaláról letöltött patch-csel. A kernel patch-ekről ("foltokról") fogok is írni a kernel-sorozatban, és majd bemutatom a unionfs patch-ével a teendőket, de most maradnék az egyszerűbb megoldáson, hogy átláthatóbb maradjon a folyamat.

Összefoglalva tehát: A unionfs egy közös nézetet biztosít különféle, amúgy fizikailag elkülönülő fájlok számára. Magyarul, két (fájl)halmazból uniót képez.


Teendők

Tehát, amit szeretnénk elérni:

1. A rendszer egy ro partícióra legyen telepítve
2. Legyen egy rw partíció, amely csak a változtatásokat tartalmazza
3. Viszonylag egyszerűen gyárthassunk új snapshotot (a rendszer új változatát), amit úgy állítunk elő, hogy az rw-n lévő változásokat visszamásoljuk az ro-ra (commit).
4. Jó ötletnek tartom a /home-ot nem belevonni a játékba, ez legyen egy harmadik partíció, amit nem bántunk. Hiszen ha gyalulunk, a user home-ját (hacsak nem a Pokoli Operátor vagyunk személyesen) nem kéne eltüntetni egy laza mozdulattal. Persze magánügy... ;-)

(folyt.köv.)

Szerencsére nem volt rá szükségem, de mégis, mi a szöszt kell Linux alatt kezdeni magunkkal, ha véletlenül letöröltünk egy fájlt? Ugyan a legtöbb grafikus környezet fájlkezelőjében van Kuka (ha valaki kivételt szeretne: LXDE), amelynek segítségével szépen megoldható a törlés utáni visszaállítás. Sőt, ahogyan olvasom, az Ubuntu 8.04-ben is bemutatkozó gvfs már tud fájlműveleteket visszagörgetni. Izgi mi? Egy másolásra is lehet azt mondani, hogy "mégse". :-)

A fájlrendszer, definíció szerint egyfajta módszer a fájljaink szervezésére és tárolására; és leírja hogy hogyan tudjuk a fájlokat rögzíteni, elérni és gyorsan megtalálni. A FAT (File Allocation Table) nevét arról kapta, ahogyan működik: van egy táblázat, amely leírja, hogy a diszk melyik területei szabadok és melyeken vannak fájlok. Ha egy fájlt törlünk, értelemszerűen nem íródik felül a diszken a tartalom, mindössze a táblázatban a megfelelő területnél bejegyzésre kerül, hogy "használható". Pofonegyszerű az egész megvalósítás, nem véletlen hogy szinte minden operációs rendszer támogatja és ezért használják a memóriakártyákon is (mellesleg szabványként is elfogadták). Egyetlen nagy hátránya (amellett, hogy nem nagy méretű diszkekre tervezték) az a bizonyos töredezettség, ami miatt folyton töredezettségmentesíteni kellett. Ez azért van, mert a területek lefoglalása a lemezen lineáris, így ha egy nem frissen létrehozott fájlhoz hozzáírunk, akkor már nem lesz szabad hely a plusz adatok mentésére ott, ahol a fájl többi része "fekszik"; az egyetlen megoldás, hogy a következő szabad helyet kell megkeresni, ami rossz esetben a fél merevlemezzel arrébb van. Nem csoda, hogy az írások-olvasások előbb-utóbb belassulnak.

Az ext2 fájlrendszer nem egyetlen, óriási táblát használ az adatok nyilvántartására, hanem egy fa-szerkezetet, amelyben blokkcsoportok az elágazások, és a blokkok a levelek (a fájl darabjai). Az ún. superblock a teljes fájlrendszerről tartalmaz infókat, mint pl. a teljes méret. Ez az első lefoglalt blokk a fájlrendszeren, enélkül nem találja meg a többi blokkot a merevlemezen. Szerencsére a superblockból van másolat mindegyik blokkcsoportban, így ha az sb megsemmisül, akkor is van lehetőség a fájlrendszer visszanyerésére. Az ún. inode-ok egy fájl minden adatát tartalmazzák, kivéve a nevét, amely ahhoz a könyvtárhoz van rendelve, amelyikben a fájl van. Amíg van legalább 15-20% szabad hely, a töredezettség létrejötte minimális, és az ext2 az egymást követő adatok olvasása/írása esetén baromi gyors; de a fájlok előkeresése csak átlagos, mivel előfordul, hogy végig kell haladni a fa egy részén.

Fogok még beszélni a proc fájlrendszerről is: ennek nem az adattárolás a célja, hanem a rendszer működésébe enged bepillantást. A /proc könyvtár alatt sok érdekes dolgot megtudhatunk az éppen futó programokról, megfelelő jogosultság megléte mellett.

Nade az igazi férfiak nem foglalkoznak holmi Kukákkal, nekem sajnos rossz szokásom Windows alatt is a shift-dellel törlés, és mivel Linuxon krónikus Midnight Commander-függő vagyok, a Kukára ott sem számíthatok. Ekkor jönnek az utolsó reménnyel kecsegtető dolgok:

0. "Biztosan van undelete Linuxra, hiszen már DOS-ban is volt" - Hát, jelentem, bukón állunk. Ugyan vannak pletykák, hogy az mc képest visszaállítani az ext2 fájlrendszert, de nekem nem volt még olyanom, amibe belefordították ezt a támogatást, így nem tudtam kipróbálni.

1. Kezdjünk komolyan foglalkozni a dologgal. Tegyük fel, hogy a fájlt letöröltük, de még meg van nyitva valamilyen alkalmazásban. Mondjuk ez egy fontos doksi, amit Ooo-ban szerkesztünk, de közben - több haszontalan fájllal együtt - véletlenül töröljük.

Ekkor jön be a képbe a /proc fájlrendszer. Ki ne lépjünk az OOo-ból! Amíg nem tesszük meg, addig sikeresen vissza tudjuk állíani a fájlt. Először is, nézzük meg, hogy mi az OOo process id-ja. A /proc könyvtár alatti, számozott könyvtárak ugyanis az éppen futó programok process id-jainak felelnek meg.
bagoj@metal:~$ ps x|grep soffice
8810 ?          Sl        0:08 /usr/lib/openoffice/program/soffice.bin -writer -splash-pipe=5
10100  pts/4  R+       0:00 grep soffice
bagoj@metal:~$ cd /proc/8810/Tehát kinéztem a PID-et bal oldalon, és beléptem a /proc/<pid> könyvtárba. Itt sok infót össze tudunk szedegetni, pl. a cat cmdline kiírja, hogy milyen parancssorral indítottuk a programot stb. de erre legfeljebb akkor van szükség, ha arra gyanakszunk hogy gonosz emberek feltörték a gépünket és kicserélték a /bin/ps programot egy hamisra; így az nem mutatja a valós állapotot. (Ez az eset kicsit messzire vezetne, hagyjuk.) Amire nekünk szükségünk van, az az fd könyvtár, amely a megnyitott fájlokat tartalmazza (fd = file descriptor, fájl leíró). Lépjünk be a könyvtárba és listázzuk, mik vannak benne:
bagoj@metal:~$ cd fd
bagoj@metal:~$ ls -la
összesen 0
dr-x------ 2 bagoj bagoj   0 2008-04-17 11:06  .
dr-xr-xr-x  6 bagoj bagoj   0 2008-04-17 09:23  ..
lr-x------  1 bagoj bagoj  64 2008-04-17 11:10 0 -> /dev/null
l-wx------  1 bagoj bagoj  64 2008-04-17 11:10 1 -> pipe:[14703]stb.... stb... itt egy rakás fájlt kiír, amit az Openoffice éppen nyitva tart. Nem érdekes, menjünk célirányosan, nekünk a fontos.doc kell:
bagoj@metal:~$ ls -la | grep fontos
lrwx------  1 bagoj bagoj 64 2008-04-17 11:10 48 -> /home/bagoj/fontos.doc (deleted)Láthatjuk, hogy meg van jelölve a fájl, mint törölt. Azonban a tartalmát még most is elérhetjük!
bagoj@metal:~$ cat 48 > /home/bagoj/alma.doc
bagoj@metal:~$ file /home/bagoj/alma.doc
/home/bagoj/alma.doc: Microsoft Word document dataTehát egyszerűen belelistázzuk a törölt fájl tartalmát egy másikba, és máris helyreállítottuk a dokumentumot! A legjobb az egészben, hogy mivel én hoztam létre a fájlt, ezért a jogom is megvolt az egészehz, nem kellett, hogy root legyek.
Ezt a trükköt szokták alkalmazni gonosz emberek is, akik létrehoznak és rögtön törölnek is egy fájlt, de egy futó programmal "nyitva tartják". Ekkor hiába keresünk rá find-dal a "gyanús dolgok.txt"-re, semmit nem fogunk találni a gépünkről összegyűjtött adatokból. Ha azonban egy jól irányzott cat-tal operálunk a /proc alatt, akkor láthatjuk a törölt fájl tartalmát.

2. Letöröljük a fájlt és éppen nincs megnyitva egyik alkalmazásban sem

Sajnos ez sokkal rosszabb eset. Nem tudjuk, hogy hol helyezkedett el a fájl a merevlemezen, hiszen levágtuk azt a bizonyos ágat a fáról. Azonnal kapcsoljuk le a gépet és igyekezzünk minél kevesebb írási művelettel megúszni (hiszen bármilyen írás felülnyomhatja a fájlunk tartalmát, mivel az a terület már felhasználható). Én, ha tényleg fontos volt a fájl, terminálban kiadnék egy sync parancsot és kikapcsolnám a gépet a power gombbal. Ez tipikusan olyan, mint amikor kaszkadőr filmekben villog a felirat, hogy "don't try this at home!", de az esetek nagy százalékában nem okozhatunk nagy bajt. Mindenesetre ilyet tényleg csak végső esetben!

Ezek után a legjobb, ha nem a vinyóról bootolunk. Jó lehet erre egy boot cd, vagy ha másik gépbe pakoljuk át a vinyót. Ezek után először elmondom a nehéz utat, majd egy sokkal könnyebbet:

a) A "UNIX-megoldás"

Mint tuggyuk, a UNIX rendszereken minden fájl. Használjuk hát ki ezt! A fájl neve, mérete stb. már elveszett, de a tartalma talán még menthető. Fontos megjegyezni, hogy ha nem valami egyszerű text fájlról volt szó, akkor szinte el is felejthetjük, hogy vissza tudjuk szerezni. Tehát a lényeg, hogy a fájl tartalmára rá tudunk greppelni, bemeneti fájlnak megadva a kérdéses merevlemez eszköznevét:
root@bootcd:~# grep --binary-files=text -B 1000 -C 4000 "Alma" /dev/hdb1 > kimenet.txtMegpróbáljuk a teljes merevlemez tartalmát végigkeresni egy adott szövegre (jelen esetben "Alma"), és az előtte lévő 1000 sortól kezdve 4000 sort kiírunk ebből egy kimenet.txt nevű fájlba. Ugye, eléggé "lájtosan" hangzik; mert az állományban ezek után kézzel kellene böngészgetni, megkeresni hogy hol is kezdődik a fájl és valahogy ebből helyreállítani. Nem lehetetlen vállalkozás, de inkább ugorjunk a következőre!

b) Visszaállítás programmal

Hoppá, mégis van undelete? Valami hasonló. Ezt úgy hívják, hogy foremost, és jó, ha mindenki most azonnal felrakja:
sudo apt-get install foremostA programnak - velünk szemben - komoly előnye, hogy fejből ismeri az ext2 fájlrendszert, valamint egy csomó fájltípus (doc,ole,htm,pdf,jpg,gif,png,bmp,avi,mpg,wmv,mov,exe,rar,zip,wav,cpp) belső szerkezetét is, így kissé nagyobb esélyekkel indul, mintha mi néznénk jojózó szemekkel hexa editorban a kimentett raw merevlemez-tartalmat...

Én még mindig azt javaslom, hogy ha lehet, kapcsoljuk ki a gépet és végezzük a visszaállítást egy másikon, de simán megpróbálhatjuk a visszaállítást azonnal a véletlen törlés után, az összes fenti hókuszpókusz kihagyásával. Azt azért nem árt tudni, hogy melyik partíciót is kell vizsgálni:
bagoj@metal:~$ mount
/dev/sda3 on / type ext3 (rw,erros=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)stb... stb... mivel az én home-om a / partíción van, nem késlekedem:
bagoj@metal:~$ sudo foremost -v -t ole,jpeg -d -T -i /dev/sda3 -o recoveredEz a recovered könyvtárba rakja az összes Microsoft dokumentum vagy jpeg fájlt, amit képes megmenteni.

És most jön a poén: mi van, ha el sem vesztettünk semmit? Ha valaki kíváncsi, hogy mondjuk elvesztett/ellopott merevlemezéről mit lehetne helyreállítani, ki lehet próbálni, a -t all paraméterrel... főleg dualbootosok fognak igencsak meglepődni.

Utóiratok:
1. az ext3-ra minden vonatkozik, ami az ext2-re; kivéve hogy az ext2-höz gyártott recovery programot (asszem, ext2recover a neve) NE futtassátok ext3-on!

2. Tudom, hogy hülye példa volt, mivel az OOo-nak van dokumentum-visszaállító rendszere.