cross-posted to SuSE formum....

I shutdown and physically moved my suse 9.0 box today. Upon restarting hung for what seemed like a long time at "grub loading stage2", then dumped me to grub command line. I was not able to do anything from the command line (perhaps should say, I don't know how to do anything from the grub command line).

Loaded the SuSE CD. Selecting the "boot from hard disk" option failed (could not find root partition).

From there I tried the repair installation option. Automatic repair does the following:

The messages, relevant to my problem, that came up were:

-> Executing file system check for partition /dev/hda2
-> Error detected
-> The Reiser file system of the partition /dev/hda2 is corrupted. To repair the file system, press "Repair"
I pressed "Repair"
-> Repair was successful

-> Executing file system check for partition /dev/hda2 (repeat)
-> Error detected
-> The Reiser file system of the partition /dev/hda2 is corrupted. To repair the file system, press "Repair"
I pressed "Repair"
-> Error: Changing environment to target system was no successful

-> Check boot loader configuration
-> Searching configuration files...
-> The following configuration files were not found: /etc/sysconfig/kernel
-> Error: The file %1 was not found. YaST can not recover this file

The repair process than ended. I still can't boot up.

I've tried knoppix, but it isn't able to mount hda2 either. I'm desperate to at least get the data off this disk, but am completely at a loss as to what to do next. Thoughts or suggestions would be very welcome!

I had a similar problem in re not being able to boot my system (after the ole lady shut it down via the power button rather than use the shutdown menu). Fortunately, my /boot is in a partition seperate from /. I booted from cd, but couldn't find my / partition. Took a few minutes of fiddling, then I discovered what was wrong. The boot cd loads it's own version of fstab, rather than using the one in /etc.
The solution to my problem was as follows:
1) su to root
2) edit the working version of fstab in memory and save. add the /dev/hda2 line with parameters and mount point.
3) cd to /mnt and create the mount point: i.e. mkdir hotstuff, or whatever.
4) mount /dev/hda2
then go to work.
So, try booting Knoppix and apply steps 1-4 to see if it works for you.

Do you have Windows running on this machine? If so, try the software found here:

http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm

Otherwise, I'm not much help.

It's not an fstab problem, nor will ext2 tools for windows help (he's useing reiserfs).

My best guess is that your computer (and therefore hard drive) got jared in the moving process. Can you access the other partitions on the disk? If you want to check for unreadable sectors without risking a write operation you can try:

dd if=/dev/hda2 of=/dev/null

In other words, read hda2 from the beginning, but ignore whatever it says. If there is a flagrant read error it will tell you.

If you want to test useing a write operation, I'd try:

badblocks -nvs

The 'n' means 'non-destructive', it reads the data and then puts it back when it's done with a section. Avoid the 'w' flag unless you give up on your data. It overwrites as it tests. You may come up with a better combonation of flags though.

There are data recovery programs for reiserfs. I have read posts of people useing them, I just don't know what their called. They're probably already on your knoppix disk somewhere.

Sorry about the tough luck. Hope things go better.

Is it too early for a celebratory drunk?

Managed to recover the data from the disk (ended up w/ 4 lost and found files, which look like system files).

Ended up using dd_rescue w/ dd_rhelp as a front end to do a direct copy of the damaged partition; was then able to work directly on the file that it created. (copies dd_rescue and dd_rhelp both available at: ftp://129.79.136.75/software/, pick the distro of your choice. Benefit over dd is that it doesn't stop at bad sectors). The new file was written to a different hd, so I was able to muck w/o further risk to the original data.

So, I went to work on the new file. Initially reiserfsck --check was failing (bread: "End of file, cannot read block"). Next tried reiserfsck --rebuildtree, which ran successfully (though w/ a few warnings). Finally, reiserfsck --rebuild-tree.

After that, mount -o loop /mnt/hdd3/dead_drive.dd /mnt/recovery did the trick. I have a mounted filesystem with what looks like everything I thought I'd lost.

Did I mention that this disk contained unbacked-up copies of my wife's dissertation research data?

Back ups, young man, backups.

After I'm sure I've recovered all the data, I'm going to try the same process on the hard disk--will see if it's just a corrupt file system (which would suggest a bad shutdown), or if it is actually a bad drive (i.e. damaged during the move).

Thanks for the tips and advice.

Congratulations!

Being a journaled file system, a bad shut down should not have been the cause. If you want to verify the drives physical integrity, I'd run badblocks or some other surface scanner. Some file system utilities (e2fsck for example for ext2/3) will rely on badblocks and use the data that comes off it to mark bad sectors to avoid using them in the future. Still, I'm not sure I would feel completely comfortable using a drive with some bad sectors.

Good luck to you, and thank you for posting your outcome and solution!