Rikard Johnels wrote:
<snip>
Pass 3a (looking for lost dir/files): Looking for lost directories: Looking for lost files: lost+found.c 348 pass_3a_look_for_lost look_for_lost: The entry 'lost+found' could not be found in the root directory. Aborted
talen:~ # ls -l /lost+found (trimmed) drwxr-xr-x 4 root root 80 Feb 10 04:09 lost+found talen:~ #
The lines; 'lost+found.c 348 pass_3a_look_for_lost look_for_lost: The entry 'lost+found' could not be found in the root directory. ' seems to be very wrong. What can i do?
Doesn't this mean the "root", or top, level of the tree on that one partition? Certainly such a directory exists at the top of every separate partition on my system, curiously -except- /. Therefore, I would think this is telling you that the lost+found directory cannot be found on /dev/hdc1. Of course, this should not be surprising, if as you say, the file table for the partition was empty. Maybe it was one of the items whose name pointed to nowhere. The reiserfsck manpage does suggest sending a bug report to the authors if a --rebuild-tree doesn't seem to produce the desired result. See also 'man debugreiserfs' particularly the -p option. Maybe debugreiserfs might even help you fix the problem youself. Another possibility might be to run --rebuild-tree again, with the --no-journal-available option, but I really have no idea what this does, and the manpage does warn us it is for experts. But lucky you, you have an image of the whole device and can restore it to its original (damaged) condition if something gets really mangled :-) The last resort is to take your drive image, and tell the client to pay a lot of money to some data recovery company, hoping they will be able to piece together the data again.