2.4.21 -> 2.4.25 cryptoloop mess

2.4.21 -> 2.4.25 cryptoloop mess

[Danny Norging]

Hi there,

since Vitaly seems not to take notice of my mail and I cant afford another
money-order (being just a student), I wonder if somebody else out there has
*any* hint on what to try next. Please have a look at this

Thanks

--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Mon, 13 Dec 2004 08:13:08 +0100 (MET)
From: "Danny Norging" <norging@gmx.de>
To: Vitaly Fertman <vitaly@namesys.com>
Subject: Re: money send, no reply? was: 2.4.21 -> 2.4.25 cryptoloop mess

Hello,

needed to buy a bigger hd so this took some time, but now i am done with
your instructions (*thanks a lot for them, i have hope*). Still a lot of
work to do, i guess... so this is what i have done:

# losetup -e aes /dev/loop0 /dev/hdc1
# dd if=/dev/loop0 of=hdc1decrypted.dump
# losetup /dev/loop1 hdc1decrypted.dump
# reiserfsck --rebuild-tree -S /dev/loop1 -l reiserfsck.log

where reiserfsck.log shows the following:
# cat reiserfsck.log 
####### Pass 0 #######
28 directory entries were hashed with "r5" hash.
####### Pass 1 #######
####### Pass 2 #######
####### Pass 3 #########
vpf-10680: The directory [2 3] has the wrong block count in the StatData (2)
- corrected to (1)
vpf-10650: The directory [2 3] has the wrong size in the StatData (720) -
corrected to (48)
####### Pass 3a (lost+found pass) #########
#

> On Monday 06 December 2004 16:21, Danny Norging wrote:
> > Hello,
> 
> Hello
> 
> > as stated in my original email (more than a month ago) I have send you
> 30$
> > to get your support, but still got no reply from you :-(
> 
> sorry for that, your email was missed somehow.
> 
> > *please* have a look at this
> >
> > thanks
> > danny
> >
> > --- Weitergeleitete Nachricht / Forwarded Message ---
> > Date: Thu, 4 Nov 2004 06:39:59 +0100 (MET)
> > From: "Danny Norging" <norging@gmx.de>
> > To: support@namesys.com
> > Subject: 2.4.21 -> 2.4.25 cryptoloop mess
> >
> > Hello,
> >
> > before I start writing about my technical problems, I just want to
> mention
> > that I sent you a money-order for 30$ back in may this year, so it would
> be
> > great if you could help me with the following...
> >
> > I have been running a gentoo gnu/linux system with 2.4.21 kernel on an
> old
> > 200mhz pentium using a second 120gb hd with a single partition for
> > samba/nfs file-serving purposes. The reiserfs on this partition was
> build
> > on top of the cryptoloop device (256bit aes), so the initial setup was
> > something like:
> >
> > # dd if=/dev/urandom of=/dev/hdc1
> > # losetup -e aes /dev/loop0 /dev/hdc1
> > # mkreiserfs /dev/loop0
> >
> > All worked without any problems until a power failure somehow corrupted
> the
> > fs :-( Unfortunately, I did a complete system update to a 2.4.25 kernel
> > trying to repair the reiserfs from this new system, and as there seems
> to
> > be a incompatibilty between the cryptoloop versions, this is where all
> > really got mixed up :-( I cant remember all the steps i took using
> > reiserfsck (at least once with the --rebuild-tree option) with the
> 2.4.25
> > kernel and later with a downgraded 2.4.21 kernel maybe on a wrongly
> > decrypted fs...
> 
> if you run reiserfsck --rebuild-tree on the device with the wrong
> decryption 
> you probably erase all the data on it. 
> 
> > End of the story is that i am now able to losetup/decrypt the partition
> > correctly (using 2.4.21 kernel again), as #hexdump -C /dev/loop0 shows
> me
> > lots of file-contents, 
> 
> do you mean that you see a lot of _correct_ file contents? 
> of files that are currently not reachable on the mounted fs?

Exactly (this is why i still have hope ;-) As this is a gentoo system there
is lots of sourcecode on the partition, and while a grep on the mounted fs
only shows this
# grep -r GNU *
Binary file lost+found/92166_92185 matches
Binary file lost+found/92196_92202 matches
Binary file lost+found/92196_92203 matches
#
i get hundreds of lines of output with
# hexdump -C /dev/loop0 | grep GNU
00012380  65 72 6d 73 20 6f 66 20  74 68 65 20 47 4e 55 20  |erms of the GNU
|
00016200  a3 21 6f 66 20 74 68 65  20 47 4e 55 20 47 65 6e  |.!of the GNU
Gen|
00016370  20 20 47 4e 55 20 47 65  6e 65 72 61 6c 20 50 75  |  GNU General
Pu|
000163c0  20 63 6f 70 79 20 6f 66  20 74 68 65 20 47 4e 55  | copy of the
GNU|
...

> > but when i mount the partition, i get the following
> > content:
> >
> > bart crypto # ls -Ral
> > .:
> > total 2
> > drwxr-xr-x    4 root     root           80 Nov  4 02:59 .
> > drwx------   11 root     root          480 Nov  4 05:14 ..
> > drwx------    4 root     root          720 Apr  3  2004 lost+found
> >
> > ./lost+found:
> > total 91
> > drwx------    4 root     root          720 Apr  3  2004 .
> > drwxr-xr-x    4 root     root           80 Nov  4 02:59 ..
> > -rwxr-x---    1 root     users         215 Jul 21  2003 1078_1080
> > -rwxr-x---    1 root     users         385 Jul 21  2003 1081_1082
> > -rwxr-x---    1 root     users         341 Jul 21  2003 1081_1083
> > -rwxr-x---    1 root     users         371 Jul 21  2003 1081_1084
> > -rwxr-x---    1 root     users    12103423998558959 Jul 21  2003
> 1081_1085
> > -rwxr-x---    1 root     users         539 Jul 21  2003 1081_1086
> > -rwxr-x---    1 root     users         407 Jul 21  2003 1081_1087
> > -rwxr-x---    1 root     users        1844 Jul 21  2003 1081_1088
> > -rwxrwxrwx    1 dnscache users        4000 Jul 24  2003 38910_45033
> > -rwxrwxrwx    1 dnscache users        2425 Jul 24  2003 38910_45034
> > -rwxrwxrwx    1 dnscache users        2865 Oct 23  2002 58627_65589
> > -rwxrwxrwx    1 dnscache users       11313 Aug  5  2003 92166_92185
> > -rwxrwxrwx    1 dnscache users         660 Aug  5  2003 92167_92168
> > -rwxrwxrwx    1 dnscache users          20 Aug  5  2003 92167_92169
> > -rwxrwxrwx    1 dnscache users          50 Aug  5  2003 92167_92170
> > drwxrwxrwt    2 dnscache users         104 Aug  5  2003 92186_92187
> > -rwxrwxrwx    1 dnscache users           2 Aug  5  2003 92187_92188
> > drwxrwxrwt    2 dnscache users         128 Aug  5  2003 92191_92192
> > -rwxrwxrwx    1 dnscache users         536 Aug  5  2003 92196_92201
> > -rwxrwxrwx    1 dnscache users       12587 Aug  5  2003 92196_92202
> > -rwxrwxrwx    1 dnscache users    742249513586003637 Aug  5  2003
> > 92196_92203
> >
> > ./lost+found/92186_92187:
> > total 10
> > drwxrwxrwt    2 dnscache users         104 Aug  5  2003 .
> > drwx------    4 root     root          720 Apr  3  2004 ..
> > -rwxrwxrwx    1 dnscache users          24 Aug  5  2003 Repository
> > -rwxrwxrwx    1 dnscache users          50 Aug  5  2003 Root
> >
> > ./lost+found/92191_92192:
> > total 14
> > drwxrwxrwt    2 dnscache users         128 Aug  5  2003 .
> > drwx------    4 root     root          720 Apr  3  2004 ..
> > -rwxrwxrwx    1 dnscache users           2 Aug  5  2003 Entries
> > -rwxrwxrwx    1 dnscache users          19 Aug  5  2003 Repository
> > -rwxrwxrwx    1 dnscache users          50 Aug  5  2003 Root
> > bart crypto #
> >
> > A reiserfsck on the crypoloop-device gives no errors:
> 
> ok, the root directory was lost and everething what was found on the fs
> was connected to the lost+found.
> 
> > bart root # reiserfsck /dev/loop0
> > reiserfsck 3.6.18 (2003 www.namesys.com)
> >
> > *************************************************************
> > ** If you are using the latest reiserfsprogs and  it fails **
> > ** please  email bug reports to reiserfs-list@namesys.com, **
> > ** providing  as  much  information  as  possible --  your **
> > ** hardware,  kernel,  patches,  settings,  all reiserfsck **
> > ** messages  (including version),  the reiserfsck logfile, **
> > ** check  the  syslog file  for  any  related information. **
> > ** If you would like advice on using this program, support **
> > ** is available  for $25 at  www.namesys.com/support.html. **
> > *************************************************************
> >
> > Will read-only check consistency of the filesystem on /dev/loop0
> > Will put log info to 'stdout'
> >
> > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > do):Yes
> > ###########
> > reiserfsck --check started at Thu Nov  4 05:18:11 2004
> > ###########
> > Replaying journal..
> > Reiserfs journal '/dev/loop0' in blocks [18..8211]: 0 transactions
> replayed
> > Checking internal tree..finished
> > Comparing bitmaps..finished
> > Checking Semantic tree:
> > finished
> > No corruptions found
> > There are on the filesystem:
> >         Leaves 3
> >         Internal nodes 1
> >         Directories 4
> >         Other files 24
> >         Data block pointers 10 (2 of them are zero)
> >         Safe links 0
> > ###########
> > reiserfsck finished at Thu Nov  4 05:18:48 2004
> > ###########
> > bart root #
> >
> > As I am afraid of doing any more harm to the fs (not sure if this is
> even
> > possible ;-) I would like to know if its possible to recover the files.
> If
> > you would like to have more debugging output, I can send you that, or
> even
> > give you a ssh-connection to the machine.
> 
> if you do not have a raw backup of the original device before rebuilding 
> the tree, let's do the following:
> * make it, the raw backup, with the dd. probably even the copy of already 
> decrypted device to make it all simplier and faster;
> * reiserfsck --rebuild-tree -S the_copy -l logfile
> 
> if this will not recover files which content you see with hexdump, we will
> try to get them manually later.
> 
> > Any help would be *great*
> >
> > Greetings from Berlin
> > Danny
> >
> >
> > --
> > NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
> > GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
> 
> -- 
> Thanks,
> Vitaly Fertman
> 
> 

Please tell me what else i can do to recover the files, TIA

Greetings from Berlin
Danny

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++


-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Sander]

Danny Norging wrote (ao):
> since Vitaly seems not to take notice of my mail and I cant afford
> another money-order (being just a student), I wonder if somebody else
> out there has *any* hint on what to try next. Please have a look at
> this

First of all I would like to tell you and others (on the list or reading
the archive/google) that you should always make a raw copy of the image
you want to fsck. Do this with dd for example. Then perform all the
actions on the copy so you can have a fresh try again later with
different (or newer) tools and options.

From your mail it seems you only made a copy after you already fsck'ed
(pun intended) the original image. Now this is your second mistake. The
first one: you didn't have (or seem to have had) backups.


> Date: Mon, 13 Dec 2004 08:13:08 +0100 (MET)
> From: "Danny Norging" <norging@gmx.de>
> 
> needed to buy a bigger hd so this took some time, but now i am done
> with your instructions (*thanks a lot for them, i have hope*). Still a
> lot of work to do, i guess... so this is what i have done:
> 
> # losetup -e aes /dev/loop0 /dev/hdc1
> # dd if=/dev/loop0 of=hdc1decrypted.dump
> # losetup /dev/loop1 hdc1decrypted.dump
> # reiserfsck --rebuild-tree -S /dev/loop1 -l reiserfsck.log
> 
> where reiserfsck.log shows the following:
> # cat reiserfsck.log 
> ####### Pass 0 #######
> 28 directory entries were hashed with "r5" hash.
> ####### Pass 1 #######
> ####### Pass 2 #######
> ####### Pass 3 #########
> vpf-10680: The directory [2 3] has the wrong block count in the StatData (2)
> - corrected to (1)
> vpf-10650: The directory [2 3] has the wrong size in the StatData (720) -
> corrected to (48)
> ####### Pass 3a (lost+found pass) #########
> #

Did you mount the fs afterwards? Did you find any new content? What
reiserfscs version did you use?


> > > From: "Danny Norging" <norging@gmx.de>
> > > To: support@namesys.com

> > > All worked without any problems until a power failure somehow
> > > corrupted the fs :-( Unfortunately, I did a complete system update
> > > to a 2.4.25 kernel trying to repair the reiserfs from this new
> > > system, and as there seems to be a incompatibilty between the
> > > cryptoloop versions, this is where all really got mixed up :-( I
> > > cant remember all the steps i took using reiserfsck (at least once
> > > with the --rebuild-tree option) with the 2.4.25 kernel and later
> > > with a downgraded 2.4.21 kernel maybe on a wrongly decrypted fs...
> > 
> > if you run reiserfsck --rebuild-tree on the device with the wrong
> > decryption 
> > you probably erase all the data on it. 

Isn't it more likely that reiserfsck in that case doesn't recognize the
filesystem at all and just exits with an error? (I'm just a user
though).


> > > End of the story is that i am now able to losetup/decrypt the
> > > partition correctly (using 2.4.21 kernel again), as #hexdump -C
> > > /dev/loop0 shows me lots of file-contents, 
> > 
> > do you mean that you see a lot of _correct_ file contents? 
> > of files that are currently not reachable on the mounted fs?
> 
> Exactly (this is why i still have hope ;-)


> > > A reiserfsck on the crypoloop-device gives no errors:
> > 
> > ok, the root directory was lost and everething what was found on the
> > fs was connected to the lost+found.


> > > As I am afraid of doing any more harm to the fs (not sure if this
> > > is even possible ;-) I would like to know if its possible to
> > > recover the files.  If you would like to have more debugging
> > > output, I can send you that, or even give you a ssh-connection to
> > > the machine.
> > 
> > if you do not have a raw backup of the original device before
> > rebuilding the tree, let's do the following:
> > * make it, the raw backup, with the dd. probably even the copy of
> > already decrypted device to make it all simplier and faster;
> > * reiserfsck --rebuild-tree -S the_copy -l logfile
> > 
> > if this will not recover files which content you see with hexdump,
> > we will try to get them manually later.

Maybe newest reiserfsck can help you out.

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Hans Reiser]

Sorry about this, it is the russian holiday season right now.  Zam will 
answer your email tomorrow.  I will complain to Vitaly about this.  He 
has no excuse for missing emails.

Hans

Danny Norging wrote:

>Hi there,
>
>since Vitaly seems not to take notice of my mail and I cant afford another
>money-order (being just a student), I wonder if somebody else out there has
>*any* hint on what to try next. Please have a look at this
>
>Thanks
>
>--- Weitergeleitete Nachricht / Forwarded Message ---
>Date: Mon, 13 Dec 2004 08:13:08 +0100 (MET)
>From: "Danny Norging" <norging@gmx.de>
>To: Vitaly Fertman <vitaly@namesys.com>
>Subject: Re: money send, no reply? was: 2.4.21 -> 2.4.25 cryptoloop mess
>
>Hello,
>
>needed to buy a bigger hd so this took some time, but now i am done with
>your instructions (*thanks a lot for them, i have hope*). Still a lot of
>work to do, i guess... so this is what i have done:
>
># losetup -e aes /dev/loop0 /dev/hdc1
># dd if=/dev/loop0 of=hdc1decrypted.dump
># losetup /dev/loop1 hdc1decrypted.dump
># reiserfsck --rebuild-tree -S /dev/loop1 -l reiserfsck.log
>
>where reiserfsck.log shows the following:
># cat reiserfsck.log 
>####### Pass 0 #######
>28 directory entries were hashed with "r5" hash.
>####### Pass 1 #######
>####### Pass 2 #######
>####### Pass 3 #########
>vpf-10680: The directory [2 3] has the wrong block count in the StatData (2)
>- corrected to (1)
>vpf-10650: The directory [2 3] has the wrong size in the StatData (720) -
>corrected to (48)
>####### Pass 3a (lost+found pass) #########
>#
>
>  
>
>>On Monday 06 December 2004 16:21, Danny Norging wrote:
>>    
>>
>>>Hello,
>>>      
>>>
>>Hello
>>
>>    
>>
>>>as stated in my original email (more than a month ago) I have send you
>>>      
>>>
>>30$
>>    
>>
>>>to get your support, but still got no reply from you :-(
>>>      
>>>
>>sorry for that, your email was missed somehow.
>>
>>    
>>
>>>*please* have a look at this
>>>
>>>thanks
>>>danny
>>>
>>>--- Weitergeleitete Nachricht / Forwarded Message ---
>>>Date: Thu, 4 Nov 2004 06:39:59 +0100 (MET)
>>>From: "Danny Norging" <norging@gmx.de>
>>>To: support@namesys.com
>>>Subject: 2.4.21 -> 2.4.25 cryptoloop mess
>>>
>>>Hello,
>>>
>>>before I start writing about my technical problems, I just want to
>>>      
>>>
>>mention
>>    
>>
>>>that I sent you a money-order for 30$ back in may this year, so it would
>>>      
>>>
>>be
>>    
>>
>>>great if you could help me with the following...
>>>
>>>I have been running a gentoo gnu/linux system with 2.4.21 kernel on an
>>>      
>>>
>>old
>>    
>>
>>>200mhz pentium using a second 120gb hd with a single partition for
>>>samba/nfs file-serving purposes. The reiserfs on this partition was
>>>      
>>>
>>build
>>    
>>
>>>on top of the cryptoloop device (256bit aes), so the initial setup was
>>>something like:
>>>
>>># dd if=/dev/urandom of=/dev/hdc1
>>># losetup -e aes /dev/loop0 /dev/hdc1
>>># mkreiserfs /dev/loop0
>>>
>>>All worked without any problems until a power failure somehow corrupted
>>>      
>>>
>>the
>>    
>>
>>>fs :-( Unfortunately, I did a complete system update to a 2.4.25 kernel
>>>trying to repair the reiserfs from this new system, and as there seems
>>>      
>>>
>>to
>>    
>>
>>>be a incompatibilty between the cryptoloop versions, this is where all
>>>really got mixed up :-( I cant remember all the steps i took using
>>>reiserfsck (at least once with the --rebuild-tree option) with the
>>>      
>>>
>>2.4.25
>>    
>>
>>>kernel and later with a downgraded 2.4.21 kernel maybe on a wrongly
>>>decrypted fs...
>>>      
>>>
>>if you run reiserfsck --rebuild-tree on the device with the wrong
>>decryption 
>>you probably erase all the data on it. 
>>
>>    
>>
>>>End of the story is that i am now able to losetup/decrypt the partition
>>>correctly (using 2.4.21 kernel again), as #hexdump -C /dev/loop0 shows
>>>      
>>>
>>me
>>    
>>
>>>lots of file-contents, 
>>>      
>>>
>>do you mean that you see a lot of _correct_ file contents? 
>>of files that are currently not reachable on the mounted fs?
>>    
>>
>
>Exactly (this is why i still have hope ;-) As this is a gentoo system there
>is lots of sourcecode on the partition, and while a grep on the mounted fs
>only shows this
># grep -r GNU *
>Binary file lost+found/92166_92185 matches
>Binary file lost+found/92196_92202 matches
>Binary file lost+found/92196_92203 matches
>#
>i get hundreds of lines of output with
># hexdump -C /dev/loop0 | grep GNU
>00012380  65 72 6d 73 20 6f 66 20  74 68 65 20 47 4e 55 20  |erms of the GNU
>|
>00016200  a3 21 6f 66 20 74 68 65  20 47 4e 55 20 47 65 6e  |.!of the GNU
>Gen|
>00016370  20 20 47 4e 55 20 47 65  6e 65 72 61 6c 20 50 75  |  GNU General
>Pu|
>000163c0  20 63 6f 70 79 20 6f 66  20 74 68 65 20 47 4e 55  | copy of the
>GNU|
>...
>
>  
>
>>>but when i mount the partition, i get the following
>>>content:
>>>
>>>bart crypto # ls -Ral
>>>.:
>>>total 2
>>>drwxr-xr-x    4 root     root           80 Nov  4 02:59 .
>>>drwx------   11 root     root          480 Nov  4 05:14 ..
>>>drwx------    4 root     root          720 Apr  3  2004 lost+found
>>>
>>>./lost+found:
>>>total 91
>>>drwx------    4 root     root          720 Apr  3  2004 .
>>>drwxr-xr-x    4 root     root           80 Nov  4 02:59 ..
>>>-rwxr-x---    1 root     users         215 Jul 21  2003 1078_1080
>>>-rwxr-x---    1 root     users         385 Jul 21  2003 1081_1082
>>>-rwxr-x---    1 root     users         341 Jul 21  2003 1081_1083
>>>-rwxr-x---    1 root     users         371 Jul 21  2003 1081_1084
>>>-rwxr-x---    1 root     users    12103423998558959 Jul 21  2003
>>>      
>>>
>>1081_1085
>>    
>>
>>>-rwxr-x---    1 root     users         539 Jul 21  2003 1081_1086
>>>-rwxr-x---    1 root     users         407 Jul 21  2003 1081_1087
>>>-rwxr-x---    1 root     users        1844 Jul 21  2003 1081_1088
>>>-rwxrwxrwx    1 dnscache users        4000 Jul 24  2003 38910_45033
>>>-rwxrwxrwx    1 dnscache users        2425 Jul 24  2003 38910_45034
>>>-rwxrwxrwx    1 dnscache users        2865 Oct 23  2002 58627_65589
>>>-rwxrwxrwx    1 dnscache users       11313 Aug  5  2003 92166_92185
>>>-rwxrwxrwx    1 dnscache users         660 Aug  5  2003 92167_92168
>>>-rwxrwxrwx    1 dnscache users          20 Aug  5  2003 92167_92169
>>>-rwxrwxrwx    1 dnscache users          50 Aug  5  2003 92167_92170
>>>drwxrwxrwt    2 dnscache users         104 Aug  5  2003 92186_92187
>>>-rwxrwxrwx    1 dnscache users           2 Aug  5  2003 92187_92188
>>>drwxrwxrwt    2 dnscache users         128 Aug  5  2003 92191_92192
>>>-rwxrwxrwx    1 dnscache users         536 Aug  5  2003 92196_92201
>>>-rwxrwxrwx    1 dnscache users       12587 Aug  5  2003 92196_92202
>>>-rwxrwxrwx    1 dnscache users    742249513586003637 Aug  5  2003
>>>92196_92203
>>>
>>>./lost+found/92186_92187:
>>>total 10
>>>drwxrwxrwt    2 dnscache users         104 Aug  5  2003 .
>>>drwx------    4 root     root          720 Apr  3  2004 ..
>>>-rwxrwxrwx    1 dnscache users          24 Aug  5  2003 Repository
>>>-rwxrwxrwx    1 dnscache users          50 Aug  5  2003 Root
>>>
>>>./lost+found/92191_92192:
>>>total 14
>>>drwxrwxrwt    2 dnscache users         128 Aug  5  2003 .
>>>drwx------    4 root     root          720 Apr  3  2004 ..
>>>-rwxrwxrwx    1 dnscache users           2 Aug  5  2003 Entries
>>>-rwxrwxrwx    1 dnscache users          19 Aug  5  2003 Repository
>>>-rwxrwxrwx    1 dnscache users          50 Aug  5  2003 Root
>>>bart crypto #
>>>
>>>A reiserfsck on the crypoloop-device gives no errors:
>>>      
>>>
>>ok, the root directory was lost and everething what was found on the fs
>>was connected to the lost+found.
>>
>>    
>>
>>>bart root # reiserfsck /dev/loop0
>>>reiserfsck 3.6.18 (2003 www.namesys.com)
>>>
>>>*************************************************************
>>>** If you are using the latest reiserfsprogs and  it fails **
>>>** please  email bug reports to reiserfs-list@namesys.com, **
>>>** providing  as  much  information  as  possible --  your **
>>>** hardware,  kernel,  patches,  settings,  all reiserfsck **
>>>** messages  (including version),  the reiserfsck logfile, **
>>>** check  the  syslog file  for  any  related information. **
>>>** If you would like advice on using this program, support **
>>>** is available  for $25 at  www.namesys.com/support.html. **
>>>*************************************************************
>>>
>>>Will read-only check consistency of the filesystem on /dev/loop0
>>>Will put log info to 'stdout'
>>>
>>>Do you want to run this program?[N/Yes] (note need to type Yes if you
>>>do):Yes
>>>###########
>>>reiserfsck --check started at Thu Nov  4 05:18:11 2004
>>>###########
>>>Replaying journal..
>>>Reiserfs journal '/dev/loop0' in blocks [18..8211]: 0 transactions
>>>      
>>>
>>replayed
>>    
>>
>>>Checking internal tree..finished
>>>Comparing bitmaps..finished
>>>Checking Semantic tree:
>>>finished
>>>No corruptions found
>>>There are on the filesystem:
>>>        Leaves 3
>>>        Internal nodes 1
>>>        Directories 4
>>>        Other files 24
>>>        Data block pointers 10 (2 of them are zero)
>>>        Safe links 0
>>>###########
>>>reiserfsck finished at Thu Nov  4 05:18:48 2004
>>>###########
>>>bart root #
>>>
>>>As I am afraid of doing any more harm to the fs (not sure if this is
>>>      
>>>
>>even
>>    
>>
>>>possible ;-) I would like to know if its possible to recover the files.
>>>      
>>>
>>If
>>    
>>
>>>you would like to have more debugging output, I can send you that, or
>>>      
>>>
>>even
>>    
>>
>>>give you a ssh-connection to the machine.
>>>      
>>>
>>if you do not have a raw backup of the original device before rebuilding 
>>the tree, let's do the following:
>>* make it, the raw backup, with the dd. probably even the copy of already 
>>decrypted device to make it all simplier and faster;
>>* reiserfsck --rebuild-tree -S the_copy -l logfile
>>
>>if this will not recover files which content you see with hexdump, we will
>>try to get them manually later.
>>
>>    
>>
>>>Any help would be *great*
>>>
>>>Greetings from Berlin
>>>Danny
>>>
>>>
>>>--
>>>NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
>>>GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
>>>      
>>>
>>-- 
>>Thanks,
>>Vitaly Fertman
>>
>>
>>    
>>
>
>Please tell me what else i can do to recover the files, TIA
>
>Greetings from Berlin
>Danny
>
>  
>

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Danny Norging]

Hi,

> Danny Norging wrote (ao):
> > since Vitaly seems not to take notice of my mail and I cant afford
> > another money-order (being just a student), I wonder if somebody else
> > out there has *any* hint on what to try next. Please have a look at
> > this
> 
> First of all I would like to tell you and others (on the list or reading
> the archive/google) that you should always make a raw copy of the image
> you want to fsck. Do this with dd for example. Then perform all the
> actions on the copy so you can have a fresh try again later with
> different (or newer) tools and options.
> 
> >From your mail it seems you only made a copy after you already fsck'ed
> (pun intended) the original image. Now this is your second mistake. The
> first one: you didn't have (or seem to have had) backups.
> 
Sad thing is when you even know all this, and it still happens to you...
just didnt get to make a big backup (no dvd-burner at the time), it was
planed, though :(

> 
> > Date: Mon, 13 Dec 2004 08:13:08 +0100 (MET)
> > From: "Danny Norging" <norging@gmx.de>
> > 
> > needed to buy a bigger hd so this took some time, but now i am done
> > with your instructions (*thanks a lot for them, i have hope*). Still a
> > lot of work to do, i guess... so this is what i have done:
> > 
> > # losetup -e aes /dev/loop0 /dev/hdc1
> > # dd if=/dev/loop0 of=hdc1decrypted.dump
> > # losetup /dev/loop1 hdc1decrypted.dump
> > # reiserfsck --rebuild-tree -S /dev/loop1 -l reiserfsck.log
> > 
> > where reiserfsck.log shows the following:
> > # cat reiserfsck.log 
> > ####### Pass 0 #######
> > 28 directory entries were hashed with "r5" hash.
> > ####### Pass 1 #######
> > ####### Pass 2 #######
> > ####### Pass 3 #########
> > vpf-10680: The directory [2 3] has the wrong block count in the StatData
> (2)
> > - corrected to (1)
> > vpf-10650: The directory [2 3] has the wrong size in the StatData (720)
> -
> > corrected to (48)
> > ####### Pass 3a (lost+found pass) #########
> > #
> 
> Did you mount the fs afterwards? Did you find any new content? What
> reiserfscs version did you use?
> 
No new content in the lost+found dir after the reiserfsck, which was version
3.6.17. I am just running a reiserfsck version 3.6.19 and will report on
those results.
> 
> > > > From: "Danny Norging" <norging@gmx.de>
> > > > To: support@namesys.com
> 
> > > > All worked without any problems until a power failure somehow
> > > > corrupted the fs :-( Unfortunately, I did a complete system update
> > > > to a 2.4.25 kernel trying to repair the reiserfs from this new
> > > > system, and as there seems to be a incompatibilty between the
> > > > cryptoloop versions, this is where all really got mixed up :-( I
> > > > cant remember all the steps i took using reiserfsck (at least once
> > > > with the --rebuild-tree option) with the 2.4.25 kernel and later
> > > > with a downgraded 2.4.21 kernel maybe on a wrongly decrypted fs...
> > > 
> > > if you run reiserfsck --rebuild-tree on the device with the wrong
> > > decryption 
> > > you probably erase all the data on it. 
> 
> Isn't it more likely that reiserfsck in that case doesn't recognize the
> filesystem at all and just exits with an error? (I'm just a user
> though).
Well, it was running for about a day, so it did something.

> 
> > > > End of the story is that i am now able to losetup/decrypt the
> > > > partition correctly (using 2.4.21 kernel again), as #hexdump -C
> > > > /dev/loop0 shows me lots of file-contents, 
> > > 
> > > do you mean that you see a lot of _correct_ file contents? 
> > > of files that are currently not reachable on the mounted fs?
> > 
> > Exactly (this is why i still have hope ;-)
> 
> 
> > > > A reiserfsck on the crypoloop-device gives no errors:
> > > 
> > > ok, the root directory was lost and everething what was found on the
> > > fs was connected to the lost+found.
> 
> 
> > > > As I am afraid of doing any more harm to the fs (not sure if this
> > > > is even possible ;-) I would like to know if its possible to
> > > > recover the files.  If you would like to have more debugging
> > > > output, I can send you that, or even give you a ssh-connection to
> > > > the machine.
> > > 
> > > if you do not have a raw backup of the original device before
> > > rebuilding the tree, let's do the following:
> > > * make it, the raw backup, with the dd. probably even the copy of
> > > already decrypted device to make it all simplier and faster;
> > > * reiserfsck --rebuild-tree -S the_copy -l logfile
> > > 
> > > if this will not recover files which content you see with hexdump,
> > > we will try to get them manually later.
> 
> Maybe newest reiserfsck can help you out.
> -- 
> Humilis IT Services and Solutions
> http://www.humilis.net
> 
Thanks
Danny

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Danny Norging]

Hi,

reiserfsck-3.6.19 just finished, still nothing new in lost+found :(
Thats what I did:

# losetup /dev/loop0 hdc1decrypted.dump
# reiserfsck --rebuild-tree -S /dev/loop0 -l reiserfsck-3.6.19.log

with the following result:
# cat reiserfsck-3.6.19.log
####### Pass 0 #######
28 directory entries were hashed with "r5" hash.
####### Pass 1 #######
####### Pass 2 #######
####### Pass 3 #########
vpf-10680: The directory [2 3] has the wrong block count in the StatData (2)
- corrected to (1)
vpf-10650: The directory [2 3] has the wrong size in the StatData (720) -
corrected to (48)
####### Pass 3a (lost+found pass) #########
#

still the content of lost+found looks like this:
# ls -Ral
.:
total 2
drwxr-xr-x  4 root root  80 Nov  4 02:59 .
drwxr-xr-x  4 root root 192 Nov 18 11:15 ..
drwx------  4 root root 720 Apr  3  2004 lost+found

./lost+found:
total 91
drwx------  4 root root                 720 Apr  3  2004 .
drwxr-xr-x  4 root root                  80 Nov  4 02:59 ..
-rwxr-x---  1 root users                215 Jul 21  2003 1078_1080
-rwxr-x---  1 root users                385 Jul 21  2003 1081_1082
-rwxr-x---  1 root users                341 Jul 21  2003 1081_1083
-rwxr-x---  1 root users                371 Jul 21  2003 1081_1084
-rwxr-x---  1 root users  12103423998558959 Jul 21  2003 1081_1085
                          ^^^^^^^^^^^^^^^^^-> quite big, isnt it?
-rwxr-x---  1 root users                539 Jul 21  2003 1081_1086
-rwxr-x---  1 root users                407 Jul 21  2003 1081_1087
-rwxr-x---  1 root users               1844 Jul 21  2003 1081_1088
-rwxrwxrwx  1 dg   users               4000 Jul 24  2003 38910_45033
-rwxrwxrwx  1 dg   users               2425 Jul 24  2003 38910_45034
-rwxrwxrwx  1 dg   users               2865 Oct 23  2002 58627_65589
-rwxrwxrwx  1 dg   users              11313 Aug  5  2003 92166_92185
-rwxrwxrwx  1 dg   users                660 Aug  5  2003 92167_92168
-rwxrwxrwx  1 dg   users                 20 Aug  5  2003 92167_92169
-rwxrwxrwx  1 dg   users                 50 Aug  5  2003 92167_92170
drwxrwxrwt  2 dg   users                104 Aug  5  2003 92186_92187
-rwxrwxrwx  1 dg   users                  2 Aug  5  2003 92187_92188
drwxrwxrwt  2 dg   users                128 Aug  5  2003 92191_92192
-rwxrwxrwx  1 dg   users                536 Aug  5  2003 92196_92201
-rwxrwxrwx  1 dg   users              12587 Aug  5  2003 92196_92202
-rwxrwxrwx  1 dg   users 742249513586003637 Aug  5  2003 92196_92203
                         ^^^^^^^^^^^^^^^^^^ ???
./lost+found/92186_92187:
total 10
drwxrwxrwt  2 dg   users 104 Aug  5  2003 .
drwx------  4 root root  720 Apr  3  2004 ..
-rwxrwxrwx  1 dg   users  24 Aug  5  2003 Repository
-rwxrwxrwx  1 dg   users  50 Aug  5  2003 Root

./lost+found/92191_92192:
total 14
drwxrwxrwt  2 dg   users 128 Aug  5  2003 .
drwx------  4 root root  720 Apr  3  2004 ..
-rwxrwxrwx  1 dg   users   2 Aug  5  2003 Entries
-rwxrwxrwx  1 dg   users  19 Aug  5  2003 Repository
-rwxrwxrwx  1 dg   users  50 Aug  5  2003 Root
#

and look at this:
# du 1081_1085 92196_92203
4       1081_1085
4       92196_92203
#

Any help? TIA

Greetings from Berlin
Danny

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Sander]

Danny Norging wrote (ao):
> > >From your mail it seems you only made a copy after you already
> > >fsck'ed
> > (pun intended) the original image. Now this is your second mistake.
> > The first one: you didn't have (or seem to have had) backups.
> 
> Sad thing is when you even know all this, and it still happens to
> you... just didnt get to make a big backup (no dvd-burner at the
> time), it was planed, though :(

My experience is that backup to disk is cheaper. Especially if it is
meant as a recovery solution (because you through away old archives as
soon as the disk get full and thus re-use space). Dvd might be cheaper
for archiving, but they have a limited lifetime.

Disk is also faster, and you can have fully automated backups. A dvd you
have to change.

I have 1.1TB disk storage at the office for automated backups and sell
our disk-based remote backup/recovery solutions to other companies.

At the moment I consider dvd storage too small, but with the upcomming
50GB dvds this might change.


> > Did you mount the fs afterwards? Did you find any new content? What
> > reiserfscs version did you use?
> 
> No new content in the lost+found dir after the reiserfsck, which was
> version 3.6.17. I am just running a reiserfsck version 3.6.19 and will
> report on those results.

Please do. I'm interested in this and hope you will succeed.


> > > > > To: support@namesys.com
> > > > if you run reiserfsck --rebuild-tree on the device with the
> > > > wrong decryption you probably erase all the data on it. 
> > 
> > Isn't it more likely that reiserfsck in that case doesn't recognize
> > the filesystem at all and just exits with an error? (I'm just a user
> > though).
>
> Well, it was running for about a day, so it did something.

Yes, that is why I believe your hope is justified.

For example, if I try to run reiserfsck (with or without --rebuild-tree)
on my swapfile, it says:

Will read-only check consistency of the filesystem on /swapfile
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /swapfile.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.


If your device was decrypted not the right way, it would contain garbage
like a swapfile contains garbage to reiserfsck, right? Reiserfsck would
not have chewed on it for a day.


-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Sander]

Danny Norging wrote (ao):
> reiserfsck-3.6.19 just finished, still nothing new in lost+found :(
> Thats what I did:
> 
> # losetup /dev/loop0 hdc1decrypted.dump
> # reiserfsck --rebuild-tree -S /dev/loop0 -l reiserfsck-3.6.19.log

This is after you ran this command with the older reiserfsck right? In
that case I would make a new copy and try again with this version on the
fresh copy. It might not make any difference at all though, but can be
worth a try.

I'm afraid (but still no Reiserfs expert) that your first --rebuild-tree
run on the original image (without the -S) did more damage than good.

It seems that the Namesys guys will help you out after the holidays.
They will have better suggestions than I have.

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: 2.4.21 -> 2.4.25 cryptoloop mess

[Vitaly Fertman]

On Sunday 09 January 2005 14:44, Danny Norging wrote:
> Hi,
>
> reiserfsck-3.6.19 just finished, still nothing new in lost+found :(
> Thats what I did:
>
> # losetup /dev/loop0 hdc1decrypted.dump
> # reiserfsck --rebuild-tree -S /dev/loop0 -l reiserfsck-3.6.19.log
>
> with the following result:
> # cat reiserfsck-3.6.19.log
> ####### Pass 0 #######
> 28 directory entries were hashed with "r5" hash.
> ####### Pass 1 #######
> ####### Pass 2 #######
> ####### Pass 3 #########
> vpf-10680: The directory [2 3] has the wrong block count in the StatData
> (2) - corrected to (1)
> vpf-10650: The directory [2 3] has the wrong size in the StatData (720) -
> corrected to (48)
> ####### Pass 3a (lost+found pass) #########
> #
>
> still the content of lost+found looks like this:
> # ls -Ral
> .:
> total 2
> drwxr-xr-x  4 root root  80 Nov  4 02:59 .
> drwxr-xr-x  4 root root 192 Nov 18 11:15 ..
> drwx------  4 root root 720 Apr  3  2004 lost+found
>
> ./lost+found:
> total 91
> drwx------  4 root root                 720 Apr  3  2004 .
> drwxr-xr-x  4 root root                  80 Nov  4 02:59 ..
> -rwxr-x---  1 root users                215 Jul 21  2003 1078_1080
> -rwxr-x---  1 root users                385 Jul 21  2003 1081_1082
> -rwxr-x---  1 root users                341 Jul 21  2003 1081_1083
> -rwxr-x---  1 root users                371 Jul 21  2003 1081_1084
> -rwxr-x---  1 root users  12103423998558959 Jul 21  2003 1081_1085
>                           ^^^^^^^^^^^^^^^^^-> quite big, isnt it?
> -rwxr-x---  1 root users                539 Jul 21  2003 1081_1086
> -rwxr-x---  1 root users                407 Jul 21  2003 1081_1087
> -rwxr-x---  1 root users               1844 Jul 21  2003 1081_1088
> -rwxrwxrwx  1 dg   users               4000 Jul 24  2003 38910_45033
> -rwxrwxrwx  1 dg   users               2425 Jul 24  2003 38910_45034
> -rwxrwxrwx  1 dg   users               2865 Oct 23  2002 58627_65589
> -rwxrwxrwx  1 dg   users              11313 Aug  5  2003 92166_92185
> -rwxrwxrwx  1 dg   users                660 Aug  5  2003 92167_92168
> -rwxrwxrwx  1 dg   users                 20 Aug  5  2003 92167_92169
> -rwxrwxrwx  1 dg   users                 50 Aug  5  2003 92167_92170
> drwxrwxrwt  2 dg   users                104 Aug  5  2003 92186_92187
> -rwxrwxrwx  1 dg   users                  2 Aug  5  2003 92187_92188
> drwxrwxrwt  2 dg   users                128 Aug  5  2003 92191_92192
> -rwxrwxrwx  1 dg   users                536 Aug  5  2003 92196_92201
> -rwxrwxrwx  1 dg   users              12587 Aug  5  2003 92196_92202
> -rwxrwxrwx  1 dg   users 742249513586003637 Aug  5  2003 92196_92203
>                          ^^^^^^^^^^^^^^^^^^ ???
> ./lost+found/92186_92187:
> total 10
> drwxrwxrwt  2 dg   users 104 Aug  5  2003 .
> drwx------  4 root root  720 Apr  3  2004 ..
> -rwxrwxrwx  1 dg   users  24 Aug  5  2003 Repository
> -rwxrwxrwx  1 dg   users  50 Aug  5  2003 Root
>
> ./lost+found/92191_92192:
> total 14
> drwxrwxrwt  2 dg   users 128 Aug  5  2003 .
> drwx------  4 root root  720 Apr  3  2004 ..
> -rwxrwxrwx  1 dg   users   2 Aug  5  2003 Entries
> -rwxrwxrwx  1 dg   users  19 Aug  5  2003 Repository
> -rwxrwxrwx  1 dg   users  50 Aug  5  2003 Root
> #
>
> and look at this:
> # du 1081_1085 92196_92203
> 4       1081_1085
> 4       92196_92203
> #
>
> Any help? TIA

I have been reported about a similar crypto problem recently, when after 
upgrade and attempt to continue using the fs, first 4 bytes of many block 
get altered. Probably your case is a similar one. If you have provided me 
an access to the fs (restored from the backup) and I have confirmed the idea, 
I could probably write a hack to pull out more data.

-- 
Thanks,
Vitaly Fertman