LinuxQuestions.org - reiserfs, corrupted/unmountable after being "initialized" in windows

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - reiserfs, corrupted/unmountable after being "initialized" in windows (https://www.linuxquestions.org/questions/linux-newbie-8/reiserfs-corrupted-unmountable-after-being-initialized-in-windows-590163/)

reiserfs, corrupted/unmountable after being "initialized" in windows

hello,

my 120gb hd (referred to as hdb, with only one partition hdb1), 98% full and no backup, is no longer mountable or corrupted, i really don't know what term to use. Its file system is reiserfs.

What exactly happened?

In windows, using Disk Management in Administrative Tools of the control panel, I "initialized" the said hd, assigned (only) a drive letter to it and made it "active". [i did this hoping that YaReg will see the partition]. Now, when i booted back to suse10.2, the os wasn't able to mount hdb1. Its appears that the fs type has been changed to fat.

I changed the type back to "native linux" using "yast2 disk".

Still, i am not able to mount it.

i run

"reiserfsck --check /dev/hdb2"
"reiserfsck --rebuild-sb /dev/hdb2"
"reiserfsck --rebuild-tree /dev/hdb2"

countless times, i can no longer remember the order of which was run first.

in running reiserfsck with the --check parameter, this is the output

Code:

bokunokage:~ # reiserfsck --check /dev/hdb1

reiserfsck 3.6.19 (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  [some url] **

*************************************************************



Will read-only check consistency of the filesystem on /dev/hdb1

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 Mon Oct  8 12:26:16 2007

###########

Replaying journal..

Reiserfs journal '/dev/hdb1' in blocks [18..8211]: 0 transactions replayed

Checking internal tree..



Bad root block 0. (--rebuild-tree did not complete)



Aborted

with rebuild tree,
it run for a long time and aborted, it was saying that no reiserfs meta was found.

with rebuild sb,

Code:

reiserfsck 3.6.19 (2003 www dot namesys dot 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  [some url] **

*************************************************************



Will check superblock and rebuild it if needed

Will put log info to 'stdout'



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

rebuild-sb: wrong tree height occured (65535), zeroed

Reiserfs super block in block 16 on 0x341 of format 3.5 with standard journal

Count of blocks on the device: 30013424

Number of bitmaps: 916

Blocksize: 4096

Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 30013424

Root block: 0

Filesystem is clean

Tree height: 0

Hash function used to sort names: "r5"

Objectid map size 2, max 1004

Journal parameters:

        Device [0x0]

        Magic [0x0]

        Size 8193 blocks (including 1 for journal header) (first block 18)

        Max transaction length 1024 blocks

        Max batch size 900 blocks

        Max commit age 30

Blocks reserved by journal: 0

Fs state field: 0xfa03:

        FATAL corruptions exist.

        some corruptions exist.

sb_version: 0

when i try to mount it, this is the output

mount /dev/hdb1 /xmac/
mount: Not a directory

when i run debugreiserfs,

Code:

Filesystem state: consistent



Reiserfs super block in block 16 on 0x341 of format 3.5 with standard journal

Count of blocks on the device: 30013424

Number of bitmaps: 916

Blocksize: 4096

Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 30013424

Root block: 0

Filesystem is clean

Tree height: 65535

Hash function used to sort names: "r5"

Objectid map size 2, max 1004

Journal parameters:

        Device [0x0]

        Magic [0x0]

        Size 8193 blocks (including 1 for journal header) (first block 18)

        Max transaction length 1024 blocks

        Max batch size 900 blocks

        Max commit age 30

Blocks reserved by journal: 0

Fs state field: 0x0:

sb_version: 0

at this point, i really dont know what to do.
can someone help me if it is still possible to recover the files in the hd? or should i already start to accept that my files are gone already?

thanks

try out testdisk, as long as you didn't write new data over what you want to restore it will look at individual bytes on the drive and restore the partition information accordingly. I've used it successfully 3 times since I first found it

I found this about initializing a partition in xp:

Quote:

Manually Initialize
Right click the new drive to initialize it (Refer to Figure 4). This prepares the drive to be used with Windows.
Once you choose initialize, another window will come up asking you to confirm which drive to initialize. Once a drive is initialized the data on the drive will be erased.

Sounds like you have wiped Linux off the map.

For your sake, I hope the suggestion proposed by farkus888 works.

i tried to use testDisk and Photorec (some brute force recovery app) and still to no avail.

however, when using testDisk, i saw that hdb1's reiserfs version is 3.5, this, i believe, should be 3.6. I remember selecting 3.5 when i ran reiserfsck --rebuild-sb the 1st time, (i know this is a big mistake, i think i selected that option since it said "recommended").

In anycase, when i try to run reiserfsck with rebuild-sb again, it doesnt ask me what version is the reiserfs is, i think because there is already an existing (corrupt) superblock.

i have a theory that if i can somehow erase out the super block, run reiserfsck with rebuild-sb again and select the right version, maybe things may work out correctly. The problem is that i dont know how to erase the superblock, any suggestions on this?? or is this even a correct way of fixing things?

as for what bigrigdriver suggested, when i used photorec, it was able to recover some files, dow they appear to be somewhat like garbage (like mp3 files of small sizes, like 15kb). i still think that somehow, the files are still there, only that data that defines the partition is damned.

Start searching the boards for "forensic".
The data may be there, but if it is, photorec should have found what it knows about. It doesn't care about the partition definition - that's testdisk's job.
ext3 offers a "last ditch" option to try and rebuild the superblocks without wiping out the inode data (see "man mkfs.ext3", for the -S option) - don't know if Reiser has similar; I have always refused to use it.

forensic needs an image of the disk or partition, apparently i do not have the resources to dd out an image 120gb big. do have any work arounds for this situation?

umm, regarding photorec, photorec is recovering files, but its appears to some trash. the files are 12-8-16-20kb in size. i tried to recover mp3 and it did find files, lots of them... i played some of them and found out that the tiny files are sound from videos stored in the hd. In example, i heard kakashi say "sakura", this is probably from the naruto episodes i have.

with this kind of recovery, do i still have the chance of getting my files back as good as they were before?? [if not, please someone tell me so that ill start to accept the fact that im really doomed]

The image is just a "safety" thing - if you *really* cock things up, you can just re-image from the (original) source and try again.
You'll also need space for the output. I keep a couple of external (USB) drives for this; they also come in handy for moving data around at other times.

Have a look at this - other than that, you might just have to accept the inevitable.

oh well,

hehehe....i guess i will have to accept that i really lost everything.

ill be wiping that hd minutes from now... for me to move on.

thanks to everyone that read this thread and helped me out.