From owner-freebsd-questions@freebsd.org Mon Feb 13 05:11:16 2017 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 5E8E2CDC287 for ; Mon, 13 Feb 2017 05:11:16 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (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 25964E2 for ; Mon, 13 Feb 2017 05:11:15 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id v1D5B3BL097538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Feb 2017 21:11:05 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id v1D5B3JY097536; Sun, 12 Feb 2017 21:11:03 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23924; Sun, 12 Feb 17 21:06:33 PST Date: Sun, 12 Feb 2017 21:06:26 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd@edvax.de Cc: freebsd-questions@freebsd.org Subject: Re: Bugs in fsck(8) and fsck_ufs(8) Message-Id: <58a13ed2.+xigeqVbOqMRyleJ%perryh@pluto.rain.com> References: <58a12387.at7Hz9kYDc2UvWNn%perryh@pluto.rain.com> <20170213044252.f78cb29d.freebsd@edvax.de> In-Reply-To: <20170213044252.f78cb29d.freebsd@edvax.de> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 05:11:16 -0000 Polytropon wrote: > On Sun, 12 Feb 2017 19:09:59 -0800, Perry Hutchison wrote: > > I have a UFS filesystem that will not mount, and it confuses fsck(8): > > > > # mount /dev/da2p2 /mnt > > mount: /dev/da2p2 : Operation not permitted > > ... fsck_ufs(8) also has trouble with this filesystem: it > > claims something is wrong, but it doesn't even identify any > > specific problems much less fix them: > > > > # fsck_ufs /dev/da2p2 > > ** /dev/da2p2 > > ** Last Mounted on /mnt > > ** Phase 1 - Check Blocks and Sizes > > ** Phase 2 - Check Pathnames > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > 13527 files, 628739 used, 43580 free (236 frags, 5418 blocks, > > 0.0% fragmentation) > > > > ***** FILE SYSTEM STILL DIRTY ***** > > > > ***** PLEASE RERUN FSCK ***** > > Do you have journaling enabled with UFS for that file system? No, it is the UFS partition of a 10.3 installation memstick (with a few additions, mostly small logfiles). > Any other "non-standard" options which might be interfering? Not that I know of. > > So it seems this filesystem also provokes a bug in fsck_ufs(8): > > any problem serious enough to not mark the filesystem as clean > > is serious enough to at least report, if not fix. (I've rerun > > it several times, always getting the same result.) > > That indicates a severe problem with the file system. Well, maybe -- but apparently not severe enough for fsck to report it :( and (I've since discovered) not severe enough to prevent mounting the filesystem read-only. After doing so I've looked around and seen no obvious corruption. > > I'd try falling back to lower-level tools, but it seems they no > > longer exist: > > > > # which icheck > > icheck: Command not found. > > > > # which dcheck > > dcheck: Command not found. > > > > # which ncheck > > ncheck: Command not found. > > > > Now what? > > A lower-level tool included with the OS is "fsdb". Unless there is more to it than I noticed in the manpage, fsdb might be useful in fixing an identified problem -- but it's not at all clear how it would be much help in identifying a problem that fsck_ufs(8) noticed but did not report.