Mit lehet tenni ha a --rebuild-tree nem tud lefutni mert bad block van és a reiserfstune-al nem lehet jelölni a rossz szektort mert "not clearly unmounted". Az egész home-on odaveszett?
- 1451 megtekintés
Hozzászólások
Le kell klónozni a lemezt (millió lehetőséged van erre; ingyenes és fizetős is: dd, ghost, acronis true image, partimage, g4u, stb.) egy hibátlan lemezre, majd a hibátlan lemezen kell futtatni a filerendszerkarbantartó és javító reiserfsck-t.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ok, akkor próbálkozom a dd-vel, az nem fog fennakadni az IO error miatt?
- A hozzászóláshoz be kell jelentkezni
apt-get install ddrescue
ddrescue --help
GNU ddrescue - Data recovery tool.
Copies data from one file or block device to another,
trying hard to rescue data in case of read errors.
illetve:
apt-get install gddrescue
Description: the GNU data recovery tool
it copies data from one file or block device (hard disc, cdrom, etc)
to another, trying hard to rescue data in case of read errors.
.
gddrescue does not truncate the output file if not asked to.
So, every time you run it on the same output file,
it tries to fill in the gaps.
.
The basic operation of ddrescue is fully automatic.
That is, you don't have to wait for an error, stop the program,
read the log, run it in reverse mode, etc.
If you use the logfile feature of ddrescue, the data is rescued
very efficiently (only the needed blocks are read).
Also you can interrupt the rescue at any time and resume it later
at the same point.
.
Automatic merging of backups: If you have two or more damaged
copies of a file, cdrom, etc, and run ddrescue on all of them,
one at a time, with the same output file, you will probably obtain
a complete and error-free file. This is so because the probability
of having damaged areas at the same places on different input files
is very low. Using the logfile, only the needed blocks are read from
the second and successive copies.
.
The logfile is periodically saved to disc. So in case of a crash you
can resume the rescue with little recopying. Also, the same logfile
can be used for multiple commands that copy different areas of the
file, and for multiple recovery attempts over different subsets.
.
gddrescue aligns its I/O buffer to the sector size so that it can be
used to read from raw devices. For efficiency reasons, also aligns it
to the memory page size if page size is a multiple of sector size.
Ha nincs apt-get, akkor helyette értelemszerűen a kedvenc és elérhető csomagkezelődet használd.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ok, feltettem, sajnos legkorábban hétfőn jutok lemezhez meg USB rackhez, sajnos a notebookomról van szó. Pont a héten néztem smartmontools-al hogy dejó mert másfél év után is milyen jónak néz ki a vinyó és remélem még bírni fogja egy darabig. Aztán egyszercsak tegnap éjjel újraindult a gép mikor bezártam a pidgint, na ilyet se láttam még. Utána elég sok mindent hiányoltam a home-omból, azóta ott tartok hogy fel se lehet mountolni mert a --rebuild-tree nem tudott lefutni és most eléggé pending az egész sajnos.
- A hozzászóláshoz be kell jelentkezni
3 hónapja történt meg velem, hogy a root fs elérte az fsck count-ot és ellenőrzést tartott. Néhány héttel előtte bővítettem a laptop-ban a merevlemezt. Az fsck nem futott le, sigle user módba kellett lépnem és egy directory-t talált invalidnak. Egy inode veszett oda, de nem volt semmi a los+found-ban. Restartoltam, és megint nem futott le az fsck. Megint kézzel folytattam és már több fájl-lal is gondja voltak. Ez így ment többször egymás után, egyre több adattal és üres lost+found-dal, amíg már nem tudott bootolni a gép.
Mondom sebaj, akkor elő a backup-ot. Egy hónapos volt a backup. A többi partícióm hibátlan volt. A SMART ugyan nem mutatott semmit, de meg voltam győződve róla, hogy az új vinyó a ludas. Átmásoltam az adatokat a backup-ra a root partíció kivételével és azt hittem, már csak annyi a feladatom, hogy upgrade-eljem a rendszer 1 hónapnyi lemaradását. Bebootoltam és nyomtam volna az uprage-et, amikor az első fordításnál sigsegv-vel elhasalt. Basszus. Második próbára máshol dobta el magát. Na rebootol-tam és toltam egy memória tesztet. És kiderült, hogy az a memória a hibás, amivel az éve elején upgrade-eltem a gépet. Tehát egy nyamvadt lefagyás nélkül lett hibás a memória úgy, hogy egyedül a root filerendszeremet korrumpálta!
Egyébként külföldön vásárolt Kingston Value RAM volt. Kértem csereszámot telefonon a Kingston-tól és itthoni szervízben gariba cserélték szó nélkül. A hiba ellenére ez egyértelműen pozitív a Value RAM-mal kapcsolatban. Kb. 1-2 hét alatt megvolt a csere. Mondjuk magamnak szereltem be, mert a laptopon már nincs gar. Már a processzort is upgrade-eltem benne és korábban volt egy alaplap csere is.
Üdv,
Dw.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Itt elvileg tuti hogy valami vinyó gond van, amikor a rossz szektort piszkálja bármi, ugyanazt a kerregést produkálja csomószor és közben alig lehet csinálni bármit hogy megszakítsam.
#badblocks -b 4096 -p 3 -s -v -n /dev/hda7 `expr 8065404 + 100` `expr 8065404 - 100`
teszt is nagyon hang-upolja a rendszert mikor a kritikus szektort akarja olvasni.
Nincs vmi instant megoldás hogy a gyanús szektort megjelöljem rossznak hogy minden elkerülje? Jó lenne. Sajna a reiserfstune-al nem megy.
A lemez uccsó 36G-s partíciójának 86%-a körül van a hiba, ha sikerül visszanyerni majd az adataimat átméretezem és nem fogom használni azt a 3-4G-t a lemez végén amíg nem veszek másik vinyót. Sajna notebook és körülményes megoldani.
- A hozzászóláshoz be kell jelentkezni