Date: Sat, 10 Mar 2018 17:01:40 -0500 From: David Bright <dab@FreeBSD.org> To: Mark Johnston <markj@FreeBSD.org> Cc: Ian Lepore <ian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs Message-ID: <D5432C3A-31C6-4C1A-8901-01E7CFA27E6B@FreeBSD.org> In-Reply-To: <20180310161701.GA73335@raichu> References: <201801151925.w0FJPCKA019434@repo.freebsd.org> <20180309220940.GG6174@raichu> <1520634689.84937.74.camel@freebsd.org> <D5627342-7FEF-47DA-AF4B-5F0D83490539@FreeBSD.org> <20180310161701.GA73335@raichu>
index | next in thread | previous in thread | raw e-mail
With regard to: fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y I don’t know how, but I completely missed the -T option for fsck when I was investigating this issue. That would be very useful, although I wanted my solution to be applicable to file systems other than ffs/ufs. With regard to the fsck_ffs behavior being a regression because formerly the FS would be mounted successfully: That was not my experience. What I observed was that the “fsck -y” would give the “please re-run” message, exit with 0 status so the boot would continue, the subsequent mount would fail because the filesystem was not clean, and *then* the boot would stop and drop to single user. -- David Bright dab@FreeBSD.orghelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D5432C3A-31C6-4C1A-8901-01E7CFA27E6B>