From owner-freebsd-questions@freebsd.org Wed Feb 10 10:57:09 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EBC0AA20FF for ; Wed, 10 Feb 2016 10:57:09 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C70A1FF4 for ; Wed, 10 Feb 2016 10:57:07 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u1AAumjd002100; Wed, 10 Feb 2016 21:56:49 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 10 Feb 2016 21:56:48 +1100 (EST) From: Ian Smith To: Polytropon cc: Paul Beard , freebsd-questions@freebsd.org Subject: Re: fsck is failing to clean a filesystem In-Reply-To: <20160210102236.19f9c68c.freebsd@edvax.de> Message-ID: <20160210204635.K51785@sola.nimnet.asn.au> References: <20160210160149.V51785@sola.nimnet.asn.au> <20160210195431.V51785@sola.nimnet.asn.au> <20160210102236.19f9c68c.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 10:57:09 -0000 On Wed, 10 Feb 2016 10:22:36 +0100, Polytropon wrote: > On Wed, 10 Feb 2016 20:11:03 +1100 (EST), Ian Smith wrote: > > On Tue, 9 Feb 2016 22:10:14 -0800, Paul Beard wrote: > > > > On Feb 9, 2016, at 9:14 PM, Ian Smith wrote: > > > > > > > > I know your problem is with /usr, but I > > > > find the fact that /var is full or too nearly so rather concerning, and > > > > wonder whether that might have contributed to your problem in some way, > > > > and whether freeing up some space there might yet help? > > > > > > Yeah, itÿÿs a mess, running a full system in a 64Gb virtual disk is > > > probably asking for trouble. I think there is some cruft in /var > > > (databases that are no longer in use) that can be pitched. > > > > 64GB should be plenty, depending on usage of course. A full /var is a > > worry, especially if it runs short of room for logging. I did makethe latter point, at least, from experience :) > When fsck is running, it usually happens in a mode where only / > is mounted read-only, and all other file systems (such as /usr > or /var) are not. So I'd say that fsck doesn't do logging > somewhere into /var/log because it doesn't exist at that time. > Single user mode is a state of heavily reduced system functionality, > but usually sufficient for solving file system problems. It's true that /var/log/* can't be written then, but it's all buffered in dmesg, saved to messages [& console.log] once syslogd starts. From single user you can say, '# dmesg >/root/dmesg.save' or a scratch disk. > > > > Also, does 'du /usr/lost+found' reveal anything? > > > > > > It was full of stuff /usr/src, best I could make out. Not sure why it > > > all ended up in there. > > > > Well at least /usr/src is easily replaced. Might be worth just deleting > > all that, though of course you need a read-write mount first .. perhaps > > after booting from a memstick or live CD? > > Which is still risky, assuming that the file system has not > been marked clean. Absolutely. I'm assuming that at this stage the choice is to newfs /usr and restore backups, unless some magic spell turns up. Once apparently losing or damaging '..' from anywhere, you're pretty much in trouble. Paul, another question: with /usr unmounted, is there anything in /usr ? > > You might also check (before and after deleting anything) that /usr > > isn't running short of inodes (df -hi)? > > Good suggestion. Only what I read; newfs defaults have always been generous for my usage. > > Just stabbing in the dark .. scrambled filesystems are the pits! > > And a good occassion to read more about UFS (McKusick et al.) - to > develop a better understanding of what's happening. :-) Good suggestion :) I envy people who've got the time these days .. cheers, Ian