This morning I had a power failure, and on reboot I got told that fsck
died with exit status 1, as logged in /var/log/fsck/checkroot:
,----
| Log of fsck -C -a -V -t ext2 /dev/hda9
| Sat Mar 1 08:04:30 2008
|
| fsck 1.40.7 (28-Feb-2008)
| [/sbin/fsck.ext2 (1) -- /] fsck.ext2 -a -C0 /dev/hda9
| / was not cleanly unmounted, check forced.
| /: 10385/60240 files (2.5% non-contiguous), 115168/240940 blocks
| fsck died with exit status 1
|
| Sat Mar 1 08:04:35 2008
| ----------------
`----
It looked a bit odd since no errors were reported. Reading the manpage:
,----
| The exit code returned by fsck is the sum of the following conditions:
| 0 - No errors
| 1 - File system errors corrected
`----
as well as the release notes:
,----
| If e2fsck sets the clean bit, but nothing else, set the exit code
| FSCK_NONDESTRUCT. After all, e2fsck did fix a filesystem error --- it
| set the filesystem valid bit when it was previously cleared. :-) This
| was needed to make the HURD fsck driver happy.
`----
I understand (CMIIW) that e2fsck will _always_ exit >= 1 if the file
system was checked because it had not been cleanly unmounted.
Since an exit value of 1 is actually okay (the errors were corrected,
after all -- nothing to worry about), consider changing the message in
that case.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24.3
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages e2fsprogs depends on:
ii e2fslibs 1.40.7-1 ext2 filesystem libraries
ii libblkid1 1.40.7-1 block device id library
ii libc6 2.7-9 GNU C Library: Shared libraries
ii libcomerr2 1.40.7-1 common error description library
ii libss2 1.40.7-1 command-line interface parsing lib
ii libuuid1 1.40.7-1 universally unique id library
e2fsprogs recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
On Sat, Mar 01, 2008 at 06:02:07PM +0100, Sven Joachim wrote:
> Package: e2fsprogs
> Version: 1.40.7-1
> Severity: wishlist
>
> This morning I had a power failure, and on reboot I got told that fsck
> died with exit status 1, as logged in /var/log/fsck/checkroot:
>
> ,----
> | Log of fsck -C -a -V -t ext2 /dev/hda9
> | Sat Mar 1 08:04:30 2008
> |
> | fsck 1.40.7 (28-Feb-2008)
> | [/sbin/fsck.ext2 (1) -- /] fsck.ext2 -a -C0 /dev/hda9
> | / was not cleanly unmounted, check forced.
> | /: 10385/60240 files (2.5% non-contiguous), 115168/240940 blocks
> | fsck died with exit status 1
> |
> | Sat Mar 1 08:04:35 2008
> | ----------------
> `----
This isn't a bug with e2fsprogs, it's a bug with the initscripts. As
you point out, an exit status of 1 means that filesystem errors are
corrected, and is a long-standing Unix convention.
/etc/init.d/checkfs.sh does the right thing.
For /etc/init.d/checkroot.sh, if the root filesystem has been modified
(which is one will generally be true if any filesystem errors have
been corrected), the appropriate response is to reboot the system,
since incorrect information may have been cached in the root
filesystem, and if the root filesystem is remounted read/write without
first rebooting, the incorrect information could get written back to
the disk, undoing fsck's good work.
So currently /etc/init.d/checkroot is doing the right thing, but it's
issuing a scary message.
But /etc/init.d/checkroot is owned by initscripts, not e2fsprogs, so
this bug needs to be reassigned to the initscripts package.
- Ted
/etc/init.d/checkroot.sh only reboots the system if fsck exits with a
value > 1, which seems in accordance with the fsck manpage.
> So currently /etc/init.d/checkroot is doing the right thing, but it's
> issuing a scary message.
The message comes from fsck, see misc/logsave.c. There is nothing in
the initscripts with prints it:
,----
| $ grep "died" $(dpkg -L initscripts)
| $ echo $?
| 1
`----
> But /etc/init.d/checkroot is owned by initscripts, not e2fsprogs, so
> this bug needs to be reassigned to the initscripts package.
I'm not convinced, but I let their maintainers decide.
Sven