I am assisting a co-woker with his server. He was having other hardware issues that were causing the server to shut off randomly. he replaced the motherboard and all was well (or so he tells me) but now, when the array is started, two disks show up as unmountable, and wants to be formatted.  The file system on each disk WAS reiserfs.  I told him many months ago to move them away from that format but he didnt. I believe there to be usable data on the disks but I am unsure on how to tell UnRAID that its reiserfs without just formatting the disks. The system has been rebooted several times since the initial issue (i was out of town and he didnt want to call me for help) so here i am with a pile of garbage and being asked to "make it work again".. 

Which version of unraid? Attach the diagnostics zip file.

6.3.2, collecting diagnostics now.

tower-diagnostics-20170327-1623.zip

Edited March 27, 20179 yr by icemansid

Bump for any good ideas? If nothing, I am going to wipe the drives tomorrow and call it a loss.

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems

Doing the reiserfsck give an unknown error.  

 

 

root@Tower:~# reiserfsck --check /dev/md3
reiserfsck 3.6.25

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

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device '/dev/md3': Unknown code er3k 127

root@Tower:~# reiserfsck --check /dev/md4
reiserfsck 3.6.25

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

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device '/dev/md4': Unknown code er3k 127

root@Tower:~#
 

Are you sure it's reiser?

 

Stop the array, change file system on both disks to auto, start the array, grab and post new diags.

Would like to add that if auto doesn't find any file system and you're sure they were reiser then it's likely there was damage to the MBR, since disk2 is same size and filesystem you can duplicate its MBR to the others using dd, check that disk2 is still sdi and disk3 sdh before doing it:

 

dd if=/dev/sdi of=/dev/sdh bs=512 count=1

 

If it works repeat for disk4

 

 

Edited March 29, 20179 yr by johnnie.black

5 hours ago, johnnie.black said:

Are you sure it's reiser?

 

Stop the array, change file system on both disks to auto, start the array, grab and post new diags.

Very sure.  diags attached. no change, still un-mountable.

tower-diagnostics-20170329-1923.zip

1 hour ago, johnnie.black said:

Would like to add that if auto doesn't find any file system and you're sure they were reiser then it's likely there was damage to the MBR, since disk2 is same size and filesystem you can duplicate its MBR to the others using dd, check that disk2 is still sdi and disk3 sdh before doing it:

 

dd if=/dev/sdi of=/dev/sdh bs=512 count=1

 

If it works repeat for disk4

 

 

root@Tower:~# dd if=/dev/sdi of=/dev/sdh bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.000144382 s, 3.5 MB/s
 

 

disks are indeed the same as before. did not work, diags attached.

tower-diagnostics-20170329-1928.zip

If the disks are really reiser the only other thing I can think of is that the superblock needs to be rebuilt but reiserfsck is not working correctly, there's a known issue with the version on unRAID v6.2.3 and --rebuild-tree, so maybe there are other problems, you should downgrade to unRAID v6.2.4 and try again to run reiserfsck.

 

 

So I've now confirmed there's also an issue on latest reiserfs-progs that if the superblock is missing or corrupt you'll get that unhelpful error, so you'll  definitely want to downgrade to v6.2.4 and run reiserfsck again.

Edited March 30, 20179 yr by johnnie.black

6 hours ago, johnnie.black said:

So I've now confirmed there's also an issue on latest reiserfs-progs that if the superblock is missing or corrupt you'll get that unhelpful error, so you'll  definitely want to downgrade to v6.2.4 and run reiserfsck again.

is there an official downgrade process?

Just copy the 3 bz* files from the v6.2.4 release and reboot.

 

If you use dockers/VMs they may not work, so run reiserfsck and when done upgrade back to v6.3.2

Edited March 30, 20179 yr by johnnie.black

So after much trial and much error, the owner of the server decided that the data wasnt worth it anymore.  it looks like 6.3.3 did address the reiserfs issues.  I will be migrating the disks to xfs before returning the server to its home. Thanks for the help.