From: "Theodore Ts'o" <tytso@mit.edu>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] fix "fsck -A" failure on a completely clean fs
Date: Fri, 10 May 2019 15:50:37 -0400 [thread overview]
Message-ID: <20190510195037.GA2534@mit.edu> (raw)
In-Reply-To: <1462601e-eca2-0270-075b-4738e4cebfed@redhat.com>
I've replied on the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1702342#c9
TL;DR: NACK
In theory you might be able to patch up e2fsck so that fsck -A
actually would work for ext[234]. It is not obvious to me that it
will work for other file systems, however --- due to some very subtle
issues such as the ones I pointed out in my reply.
Cheers,
- Ted
On Fri, May 10, 2019 at 04:19:47PM +0200, Denys Vlasenko wrote:
> Before remounting root fs and mounting local filesystems
> in /etc/fstab, my boot scripts check them for errors with:
>
> if ! fsck -A; then
> echo "fsck exit code: $?. Boot will not continue."
> while true; do sleep 9999; done
> fi
> mount -o remount,rw /
> mount -a
>
> Looks like something very straightforward, right?
>
> I have two filesystems in /etc/fstab:
> /dev/sda2 / ext4 defaults 1 1
> /dev/sda1 /boot ext4 defaults 1 2
>
> If I use fsck from util-linux-2.33.2-1.fc31.x86_64 (IOW: rather recent code),
> it starts two instances of fsck.ext4 (all is fine with it).
>
> The second one's stdio is redirected (probably to /dev/null),
> it is no longer the tty. (Which is fine too).
>
> But now we hit a problem. Second fsck.ext4 flat out refuses to do its job,
> even before it looks at the filesystem.
>
> Therefore, this condition does not trigger:
> if (getenv("E2FSCK_FORCE_INTERACTIVE") || (isatty(0) && isatty(1))) {
> ctx->interactive = 1;
> }
> and ctx->interactive stays 0.
> Therefore, later in main() fsck.ext4 dies with this message:
> if (!(ctx->options & E2F_OPT_PREEN) &&
> !(ctx->options & E2F_OPT_NO) &&
> !(ctx->options & E2F_OPT_YES)) {
> if (!ctx->interactive)
> fatal_error(ctx,
> _("need terminal for interactive repairs"));
> }
>
> This happens BEFORE any repairs are deemed necessary, IOW: it happens ALWAYS,
> even if filesystem is completely fine.
>
> IOW: "fsck -A" is *completely unusable* in this scenario.
> I believe this is wrong. It is intended to be the generic, fs-agnostic way
> to run fsck's on all /etc/fstab filesystems.
>
> I propose to change the code so that this abort happens only if we
> indeed need to interactively ask something.
>
> Tested patch attached.
>
> Fedora BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1702342
>
> diff -uprN e2fsprogs-1.44.4.orig/e2fsck/unix.c e2fsprogs-1.44.4/e2fsck/unix.c
> --- e2fsprogs-1.44.4.orig/e2fsck/unix.c 2018-08-19 04:26:58.000000000 +0200
> +++ e2fsprogs-1.44.4/e2fsck/unix.c 2019-04-23 15:38:55.890507270 +0200
> @@ -1439,13 +1439,6 @@ int main (int argc, char *argv[])
>
> check_mount(ctx);
>
> - if (!(ctx->options & E2F_OPT_PREEN) &&
> - !(ctx->options & E2F_OPT_NO) &&
> - !(ctx->options & E2F_OPT_YES)) {
> - if (!ctx->interactive)
> - fatal_error(ctx,
> - _("need terminal for interactive repairs"));
> - }
> ctx->superblock = ctx->use_superblock;
>
> flags = EXT2_FLAG_SKIP_MMP;
> diff -uprN e2fsprogs-1.44.4.orig/e2fsck/util.c e2fsprogs-1.44.4/e2fsck/util.c
> --- e2fsprogs-1.44.4.orig/e2fsck/util.c 2018-08-19 04:26:58.000000000 +0200
> +++ e2fsprogs-1.44.4/e2fsck/util.c 2019-04-23 15:39:27.571448855 +0200
> @@ -203,6 +203,14 @@ int ask_yn(e2fsck_t ctx, const char * st
> const char *extra_prompt = "";
> static int yes_answers;
>
> + if (!(ctx->options & E2F_OPT_PREEN) &&
> + !(ctx->options & E2F_OPT_NO) &&
> + !(ctx->options & E2F_OPT_YES)) {
> + if (!ctx->interactive)
> + fatal_error(ctx,
> + _("need terminal for interactive repairs"));
> + }
> +
> #ifdef HAVE_TERMIOS_H
> struct termios termios, tmp;
>
prev parent reply other threads:[~2019-05-10 19:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 14:19 [PATCH] fix "fsck -A" failure on a completely clean fs Denys Vlasenko
2019-05-10 19:50 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190510195037.GA2534@mit.edu \
--to=tytso@mit.edu \
--cc=dvlasenk@redhat.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.