Reiserfs has killed my root FS!?!

Firstly, I haven't subscribed to this list since 2.3 so please also copy me on repsonses.
Secondly, I am e-mailing from my Mother's place as it IS Mother's Day AND my home PC will no longer boot Linux (my primary OS), so please send responses to [email protected] TIA :-)

Now the problem.
I use reiserfs on all my filesystems. I have noticed some minor corruption of files in the past when I didnt shut down Linux properly (lockups, etc). I experiment alot with my computer.

Anyway lately I was havin a problem that required frequent reboots. Now I believe my root filesystem is corrupted?!? Linux 2.4.18 boots till it gets to

reiserfs: checking transaction log (device 08:12)
attempt to access beyond end of device
08:12: rw=0 want=268574776 limit=8747392
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1 2 0x0 SD] Using r5 hash to sort names
Reiserfs version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Warning: unable to mount devfs, err: -5
Freeing unused kernel memory: 224k freed
Warning: unable to open an initial console.

Kernel panic: No init found.

If someone can get me to the point where I can just get to read my filesystem read-only, so I get get all my data off of it, I would be EXTREMELY GRATEFUL! I have some very important data on that FS. I went to the reiserfs web site to discover I'd get charged $25 for asking for help, so unless someone convinces me otherwise, I will be converting to EXT3 when this disaster is over...

Slackware Linux 8.1b2
Linux 2.4.18
ReiserFS 3.6.25
GLIBC 2.2.5
GCC 2.95.3

Any help please?!?
John O'Donnell
[email protected]

I'm not an expert, but this perhaps isn't a reiserfs problem.
I'm using reiserfs and i've never had a problem. The only corruption i've seen is
while compiling kernel. The .o file was being created, and if i shut down the computer, at restart, when i try to compile the kernel again, gcc says that doesn't understands the .o file This was because when replaying the journal the file was created, but it has random data. This is normal, because reiserfs only assures the metadata integrity, not the data.

Hi,

Nope. It looks much more like the IDE problem Tomas Szepe addressed in "2.5.15 IDE possibly trying to scribble beyond end of device"

http://marc.theaimsgroup.com/?l=linux-kernel&m=102102901525874&w=2

Regards,
Thunder

Was it a black who passed anong in the sand?
Was it a white who left his footprints?
Was it an african? An indian?
Sand says, 'twas human.

... except that he's using 2.4

BTW, what had caused these reboots? If it was memory corruption anywhere - all bets are off and no journalling will save you. Contrary to the popular myth, journalling filesystems (or soft-updates, or mounting everything full-sync) do _NOT_ protect against hardware problems and kernel bugs.

Well, judging by
<quote>
I use reiserfs on all my filesystems. I have noticed some minor corruption of files in the past when I didnt shut down Linux properly (lockups, etc). I experiment alot with my computer.

Anyway lately I was havin a problem that required frequent reboots.
</quote>

I'd assume this bloke might have booted 2.5.15, only he's not mentioning it.

T.

I'm sorry. This IS 2.4.18 - I havent played with 2.5 yet - but thanks for the warning. This is a Seagate ST39102LW hooked into an Adaptec 29160.

I am writing this in my WinDOS 98 mozilla. I feel so dirty :-)
Well at least it's mozilla. :-)
Johnny O

Hello!

Ok, if you want your fs back, correct way is to download latest preversion of reiserfsprogs (reiserfsprogs-3.x.1c-pre4 for now) from namesys.com ftp site, build it somewhere, boot off rescue media of some kind, and then run reiserfsck with --rebuild-tree argument (and a path to your partition of course). If you cannot build any binaries anywhere, I can send you a binary of reiserfsck.
You problem is that pointer to data block got corrupted and now points outside of the partition.
(notw, if you have some reiserfsck version on your rescue media, it won't help you, because this exact problem got fixed only recently)

Bye,
Oleg

Hi John,

you have root mounted read-only, and devfs enabled. I think you get into trouble because of devfs. Without the devices you can't get the console and thus you can't do anything with the computer. Furtheron init will try to create the .initctl pipe in /dev, which is due to the not mounted devfs in a directory of the READ-ONLY root.

My guess: Your flesystem is readable and (mostly) correct. As some others before me mentioned -- we don't know what you did of course.

My hint: Take your recovery floppies to get into your host. For the case you don't have some, take the installation floppies from some distro.

Best wishes
Frank

Well.......
I sorta DISCOVERED THIS!
But, I bow to Oleg anyway!!!!!!!!!!!!!!!!!!
Great utilities!!!!!!!!!!!!!!!!!!!!!!!

Before seeing this I installed Slack 8.0 on another small partition, downloaded 2.4.18, latest reiser tools from slack's site. I had to so a --rebuild-sb thought first. Then the rebuild tree.....

Now I am back in Linux heaven! It just booted.

Oh man these errors freaked me the hell out.
I am still turned off by seeing the $25/per question for support on namesys.com after clicking on "Support" with NO mention of the mailing list. I found the mailing list LATER and some useful tips.

My brain kernel paniced!

Root FS backup commences...... :-)

Thank you Oleg!
Johnny O

=== Never ask a geek why, just nod your head and slowly back away.===
+==============================+====================================+
| John O'Donnell               |                                    |
|  (Sr. Systems Engineer,      | http://johnnyo.home.mindspring.com |
|  Net Admin, Webmaster, etc.) |   E-Mail: [email protected]   |
+==============================+====================================+

Sorry to bother you, but are you sure you spelled it correctly? The latest I could find was 3.x.1c-pre3 on the namesys ftp server.
I have the same problem on a machine (made worse by the fact that the filesystem was a RAID0 partition).
I keep getting "wrong superblock", even after I told reiserfsck to rebuild the superblock.
I won't pretend I know much about filesystems, so - is my situation hopeless? (meaning, does RAID mess things up even worse?) Am I doing something wrong? Is there a difference between -pre3 and -pre4 which might change the response of --rebuild-tree?

Thanks for any help

Eugenio

Hello!

I am.

Hm. -pre4 is not public yet, it seems.

You mean, after the --rebuild-sb command?

What exactly have happened to your FS, BTW?

--rebuild-tree needs valid superblock, I think.

Bye,
Oleg

Sorry.

Yes. The first time I ran reiserfsck --rebuild-tree it told me to rebuild the superblock and so I ran --rebuild-sb. The startup messages only say the format is 3.5.x, so I selected the <=3.5.9 option

A complete - and so far unexplained - system freeze. The distro is SuSE 7.3, kernel 2.4.10. I have used it at home ever since it came out without a single problem, so I'm quite surprised it died after a few days of operations just serving a Samba share and acting as a Squid proxy at the office (6-7 people using it, not heavy traffic).

The screen was blank and it needed a hard reboot. After the reboot I had the same error the initial post reported.

I do not know if the raid0 partition failed in some way and it crashed the system, or whether the system froze for some ther reason and the hard reboot messed up the partition as well - although I tend to favor the second case. I might have forgotten to disable APM, which on a number of Dell machines has given me problems (the box is an old Dell XPS with a 266 MHz PII). Possibly, APM kicked in and it froze the machine - but I'm surprised this happened after over a week of continued operations.

Well, I'll be very grateful for any insight you can offer

Eugenio

Hello!

This is a mistake.
You need to choose other, more recent format.
It is highly unlikely you might have format of version <=3.5.9 If you have not done rebuild-tree after that again - you may do --rebuild-sb and choose more recent format, then it should help.

2.4.10 is way too old.

First of all make sure that your raid array same up fully.
This is very important! Check all the partitions if they are of correct size. Then do rebild-sb and choose more correct superblock version (if asked). If you are not asked for the fs version, that's bad. Let us know then.

After that you might try to do --rebuild-sb and that one should help.

I see this --rebuild-sb causes a lot of confusion for people, when it asks the format, I am going to make it to offer some hints.
Thanks for your report.

Bye,
Oleg

Already done. I booted with the rescue system from the installation CD and I rewrote /etc/raidtab. The partition table seems OK, the partitions
have the correct sizes and the correct types.
The raid array starts fine and /proc/mdstat reports everything OK

Just done that.
It's asked me the fs type and I've entered the one you told me. It seemed to work. I ran --rebuild-tree after that and it started replaying the journal - which it had not done before - but then it still died with "wrong superblock". The exact message is:

init_source_bitmap: bitmap 0 (of 6450048 bits) is wrong - make all blocks [0-32768] as used

init_control_bitmap: wrong super block

I guess I made things worse with my initial attempt as rebuilding the superblock.

BTW - I tried, as I have nothing to lose at this point :) - to re-do --rebuild-sb and now it doesn't ask for the version

Thanks very much for your help

Eugenio