Re: Erased start of voulme...

["E.Gryaznova" <grev@namesys.com>]

Louis Erickson wrote:

>Wow, thanks for the fast responses, everyone.  I'll try and consolidate 
>them all in to one reply, in the order I got them here.
>
>Silly me forgot to start ssh on the afflicted box, so I can't get to it 
>until I get home.  I do have another near-identical machine that I've 
>checked versions and such on, and can use to build tools if need be.
>
>On Fri, 14 Jan 2005, Sander <sander@humilis.net> wrote:
>
>  
>
>>What arguments did you use?
>>    
>>
>
>reiserfsck --check /dev/md2
>
>  
>
>>What version of reiserfsck?
>>    
>>
>
>How do I find that out?  It isn't in the help or visible as an option.  
>If I ask mkfs.reiserfs it tells me it's 3.x.1b (2002).  I suspect it's 
>quite old.
>  
>
please try the latest reiserfsprogs-3.6.19.tar.gz from 
ftp://namesys.com/pub/reiserfsprogs

>Should I build new tools (on another similar machine) and use those 
>instead?
>  
>
>  
>
>>And what filesystem?
>>    
>>
>
>It's /dev/md2, mounting on /var.  Linux is unhappy without it, although it 
>does come up to single user mode.  Much of the important data is on /home, 
>and I can therefore get off if I have to completely rebuild, but there's a 
>couple of things (/var/mail, for instance) that would be good to rescue.  
>I'd like to try and get a gander at /var/log too, to see if I can suss out 
>what happened.
>
>All of this is running on software raid, but the volumes are all up and 
>good, and the raid component isn't complaining at all.
>
>Or is that not the question you're asking?
>
>  
>
>>_And_ it is a lesson why backups are important :-)
>>    
>>
>
>Yes it is.  It is past time to fix this astonishing lack in our 
>infrastructure.
>
>On Fri, 14 Jan 2005, Alex Zarochentsev <zam@namesys.com> wrote:
>
>  
>
>>reiserfsck --rebuild-sb can re-create the super block.
>>    
>>
>
>I saw that, but it looked dangerous, and I didn't want to try it until my 
>copy had finished.
>
>On Fri, 14 Jan 2005, E.Gryaznova <grev@namesys.com> wrote:
>
>  
>
>>I would prefer to do the following :
>>dd if=/dev/problem_partition of=/dev/sparedevice
>>sparedevice can be usual disk partition
>>    
>>
>
>I don't have a spare partition large enough in this system.  I have done:
>
>dd if=/dev/problem_partition of=/home/scratch/rescue.dat
>
>I'll then use the loopback file system to create a device entry for that 
>file, and work on that.  It was a suggestion made earlier on this very 
>mailing list, and it sounded like a wise one to me.  If the loopback 
>doesn't work, I'll fiddle around with hardware to make a spare partition 
>large enough available.
>
>  
>
>>then
>>reiserfsck --rebuild-sb /dev/sparedevice
>>reiserfsck --check /dev/sparedevice
>>    
>>
>
>The help screen for --rebuild-sb says that a --rebuild-sb will require a 
>--rebuild-tree afterwards.  Should I try that, or the --check? 
>
new reiserfsck (3.6.19)  asks to run  --check after --rebuild-sb

> Or will 
>--check do the --rebuild-sb as needed?
>
>Also, there's a -S/--scan-whole-partition option... should I use that to 
>make sure no files are missed, or would it best not to add that?
>  
>
if you have a copy of corrupted fs -- you may try both ways (w/ and w/o 
-S) and see what way is more successful

Good luck!
Lena

>Again, thank you all for your quick replies.  It's been very helpful, and 
>very positive to hear there are things I can at least try, rather than 
>that I am simply hosed.
>
>  
>