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