NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
bin/48714: fsck prompts only appear after being answered
>Number: 48714
>Category: bin
>Synopsis: fsck prompts only appear after being answered
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Apr 05 19:20:00 +0000 2014
>Originator: Andreas Gustafsson
>Release: NetBSD 6.1.3
>Organization:
>Environment:
System: NetBSD 6.1.3
Architecture: x86_64
Machine: amd64
>Description:
When booting a NetBSD 6.1.3 system after a crash where fsck needs to
perform an interactive repair, fsck appears to hang. For example,
it may print a message such as
INCORRECT BLOCK COUNT I=252276 (1600 should be 416)
but then nothing more happens, no matter how long I wait.
However, if I press control-C on the console at this point, I get the
following output:
^CCORRECT? [yn] Unknown error 130; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
[1] Terminated (stty status "^T...
Note the "CORRECT? [yn]" prompt. It looks like fsck was actually
waiting for operator input, but the prompt never appeared on the
console until fsck was interrupted by the SIGINT.
If instead of pressing control-C, I blindly type "y" and press enter,
without having been prompted to do so, fsck accepts the input and
continues, printing the prompt *after* the answer to it:
** Phase 4 - Check Reference Counts
LINK COUNT FILE I=174911 OWNER=0 MODE=100444
SIZE=1539 MTIME=Apr 5 14:02 2014 COUNT 2 SHOULD BE 1
y
ADJUST? [yn]
I first noticed this problem on an i386 system that has been upgraded
to 6.1.3 from an earlier NetBSD version, and as a result of that
upgrade path, does not mount its root file system with "-o log",
and has fsck_flags="" by default.
Reproducing the bug on a fresh 6.1.3 install is harder because WAPBL
is now enabled by default, causing fsck to be bypassed in most cases,
and fsck_flags is set to "-p" by default, causing fsck to not prompt
the operator for minor problems. Nonetheless, I have reproduced it on
a fresh 6.1.3/amd64 install by disabling WAPBL and setting
fsck_flags="".
The problem only occurs in the fsck run automatically from the rc
scripts; rerunning fsck manually from the single-user shell prompt,
the fsck prompts appear as expected, before being answered.
The bug also affects -current as of source date 2014.04.03.15.24.20.
>How-To-Repeat:
# mount -u /
# echo 'fsck_flags=""' >>/etc/rc.conf
Do an unclean shutdown and reboot, for example:
Break into ddb in the middle of unpacking a tarball
Type "reboot 0x4"
>Fix:
Home |
Main Index |
Thread Index |
Old Index