Before remounting root fs and mounting local filesystems in /etc/fstab, my boot scripts check them for errors with: if fsck -A; then true else echo "fsck exit code: $?. Boot will not continue." while true; do sleep 9999; done fi mount -o remount,rw / mount -a 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, it starts two instances of fsck.ext4, and the second one's stdio is redirected (probably to /dev/null), it is no longer the tty. 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. I propose to change the code so that this abort happens only if we indeed need to interactively ask something. Tested patch attached.
Created attachment 1557733 [details] Proposed patch
Are those standard Fedora boot-time scripts, or something custom? Wouldn't it be better to make it run in "preen" (auto) mode and not run it in a mode where interactivity may be required?
(In reply to Eric Sandeen from comment #2) > Are those standard Fedora boot-time scripts, or something custom? It's custom. > Wouldn't it be better to make it run in "preen" (auto) mode and not run it > in a mode where interactivity may be required? I'm not running fsck.ext4 *directly*, thus I can't control the options it gets. I simply execute "fsck -A". _It_ decides what tools to run to fsck filesystems, based on their fs types. _It_ supplies command-line options.
There's no way for e2fsck to know when it starts whether or not you will need interactive repairs, so it simply looks at the mode you asked for. I don't know if it would fly upstream to let an interactive repair start without a terminal, and succeed or fail based on whether or not it eventually finds a problem. This would be a departure from the current expected mechanism. Why not invoke it as fsck -Aa ? AFAICT this will do what you want. Although not guaranteed, the following options are supported by most filesys‐ tem checkers: -a Automatically repair the filesystem without any questions (use this option with caution). Note that e2fsck(8) supports -a for backward compatibility only. This option is mapped to e2fsck's -p option which is safe to use, unlike the -a option that some filesystem checkers support. -Eric
(In reply to Eric Sandeen from comment #4) > There's no way for e2fsck to know when it starts whether or not you will > need interactive repairs There is a way to know that: when e2fsck is going to print a prompt and read an answer, it's definitely an indication e2fsck needs interactive repairs. That's exactly the fact my patch uses: I moved the code to complain & abort (if tty is not available) to the location where "print a prompt, read an answer" is about to happen.
(In reply to Eric Sandeen from comment #4) > Why not invoke it as fsck -Aa ? AFAICT this will do what you want. > > Although not guaranteed, the following options are supported by most > filesystem checkers: > > -a Automatically repair the filesystem without any questions > (use this option with caution). (1) it's not guaranteed to be supported by fsck's. But more importantly: (2) I don't *want* automatic repairs. If fs is non-trivially damaged, I *want* boot to stop and wait for me to decide how to proceed.
Denys, feel free to send the proposed patch to the upstream list (linux-ext4.org). From my POV it makes more sense in this case, in interactive mode with no terminal available, to just behave as if -n option was given. On the other hand the argument could be made that whatever wants to call fsck.extN non-interactively should actually intentionally do so by providing desired option. -Lukas
(In reply to Lukáš Czerner from comment #7) > Denys, > > feel free to send the proposed patch to the upstream list > (linux-ext4.org). From my POV it makes more sense in this case, > in interactive mode with no terminal available, to just behave as if -n > option was given. > On the other hand the argument could be made that whatever > wants to call fsck.extN non-interactively should actually intentionally do > so by providing desired option. You still miss my point. Let me restate. With the current code, "fsck -A" is UTTERLY, COMPLETELY BROKEN: it fails ***EVEN ON A CLEAN FILESYSTEM WHICH REQUIRES NO REPAIRS***. Don't you think "fsck -A" supposed to be working?
1) Given that all distributions use fsck -Aa or fsck -Ap in their standard boot scripts --- and this has been true for decades for Linux, and even longer if you consider BSD (which is where this convention originated), in practice all fsck.* programs will support -a and -p. 2) You stated: "I don't *want* automatic repairs. If fs is non-trivially damaged, I *want* boot to stop and wait for me to decide how to proceed.". That is in fact, the *definition* of -p. 3) fsck -A will run the back-end fsck.* programs in parallel. One of the things -p does is it makes sure the messages are printed in a way that the messages will be intelligible if there are messages being emitted from multiple fsck programs running in parallel, and needing to write messages to stdout. So no, I don't want to encourage fsck -A, because there are multiple reasons why it won't work. 4) Another reasons why your patch won't do the right thing is there are some completely normal things that you **really** want e2fsck if automatically. For example, ext4 doesn't update the free_blocks_count and free_inodes_count fields in the superblock. So in pass 5, e2fsck in interactive mode will ask permission to update these fields. With your patch, e2fsck will stop --- and you will be sad. More seriously, e2fsck will offer to optimize extent trees: Inode 12 extent tree (at level 1) could be shorter. Optimize? yes Hence, with your patch, fsck -A will still result in e2fsck stopping your boot on completely valid file systems. e2fsck in interactive mode is *not* intended to be used in fsck -A. So you really want to run fsck -An, fsck -Ay, or fsck -Ap --- with fsck -Ap the choice that makes the most sense for most users ---- which is why all distributions tend to use this in their boot scripts.
I propose to modify fsck manpage with the above information.
Already in the fsck man page: -s Serialize fsck operations. This is a good idea if you are checking multiple filesystems and the checkers are in an inter‐ active mode. (Note: e2fsck(8) runs in an interactive mode by default. To make e2fsck(8) run in a non-interactive mode, you must either specify the -p or -a option, if you wish for errors to be corrected automatically, or the -n option if you do not.) And earlier, in the Description: Normally, the fsck program will try to handle filesystems on different physical disk drives in parallel to reduce the total amount of time needed to check all of them. If you think something more explicit should be added to the fsck man page, feel free to try to negotiate with the util-linux maintainer about how much more tutorial information should be added to the fsck man page, especially given that 99.999999% of users will be using the Distro-provided init scripts, and this information has been known to system administrators for decades....
Closing this bug for Fedora, if anything does change it's clear that it will need to be negotiated upstream. (comments can continue, just taking this off the open bug list for now) Thanks, -Eric