Michael Wahlbrink wrote:
Eric Sandeen wrote:
Ok, two things here then. Apparently your filesystem thinks it was not
shut down cleanly; it's doing recovery. Then recovery fails, and it
can't mount the root FS so you get the panic. To quote Steve, "Bad
clientid means there was something in the log which was not
recognized." I don't know for sure what might have caused this, it
seems like write caching could be the culprit.
What version is the kernel? I wonder where the XFS bits came from.
The Kernel is a 2.4.18 from kernel.org with the xfs-1.1-2.4.18-all.patch
patch from oss.sgi.com :-|
nothing special or have I missed something? ;-)
I would make sure write caching is off on the IDE drives and see if that
solves the problem (will change your performance quite a bit too, I'm
afraid.)
It's slow enough with cache - how will it be without? ;-)
I'll go home and try this .....
-Eric
Ok, was at home to get the stuff working, but ......
I booted my 'repairsystem' and tried the usual xfs_repair (-L) commands
out of the bash-history, but this time they fail.
# xfs_repair -L /dev/ataraid/d0p1
xfs_repair: warning - cannot set blocksize on block device
/dev/ataraid/d0p1: Invalid argument
Phase 1 - find and verify superblock ...
Phase 2 - using internal log
- zero log ...
xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record:
Assertion 'start_blk !=0 || *last_blk != start_blk' failed.
Aborted.
Hmmm, looks bad for my system :o
Any chance left to get my system / data back or have I to do the mkfs
again? ;-/
regards
micha
|