Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KMVunC029079 for ; Mon, 20 May 2002 15:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KMVugW029078 for linux-xfs-outgoing; Mon, 20 May 2002 15:31:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KMVknC029052 for ; Mon, 20 May 2002 15:31:47 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 65B3D1D805; Tue, 21 May 2002 00:32:28 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052100322802:6954 ; Tue, 21 May 2002 00:32:28 +0200 Message-ID: <3CE97985.8060405@propack-data.com> Date: Tue, 21 May 2002 00:32:37 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs , Eric Sandeen Subject: Re: problems with xfs as root fs References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> <3CE9648E.70403@propack-data.com> <1021929167.2249.8.camel@stout.americas.sgi.com> <3CE9687B.4070102@propack-data.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 21.05.2002 00:32:28, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 21.05.2002 00:32:28, Serialize complete at 21.05.2002 00:32:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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