FS#18141 - [initscripts] fsck return '8' not '32' on control-c during forced check during boot.

Attached to Project: Arch Linux
Opened by Tom (hungerfish) - Wednesday, 03 February 2010, 08:55 GMT
Last edited by Thomas Bächler (brain0) - Monday, 28 February 2011, 16:17 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
All partitions are forced to be fscked after so and so many boots, which is fine.
Recently, my very large / very full /home needed to be check. I aborted the check with 'control-c' as I was in a hurry, expecting to be able to continue to boot. But I was dropped to 'control-d or sulogin', where control-d reboots the system, upon which the forced check comes up again, meaning I really am 'forced'...

I posted about this on arch-general, and the feedback I got suggested that this shouldn't happen.
Somebody suggested to try and see what fsck is returning, I did, it gives back '8 - Operational error' , not '32 - Fsck canceled by user request'

So either /etc/sysinit is handling this wrong, of fsck is somehow broken.

Additional info:
testing/initscripts 2010.01-1 but also on older version
core/e2fsprogs 1.41.9-1, this is on an ext4 partition

Steps to reproduce:

In /etc/rc.sysinit:

if [ ${fsckret} -gt 1 -a ${fsckret} -ne 32 ]; then
...
echo "${fsckret}"

and obviously a forced check.
This task depends upon

Closed by  Thomas Bächler (brain0)
Monday, 28 February 2011, 16:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in e2fsprogs, apparently.
Comment by Paul Mattal (paul) - Saturday, 06 March 2010, 03:13 GMT
I would expect the fsck.<fs> for each type to be responsible for the return value. What fs(es) are you using?
Comment by Tom (hungerfish) - Saturday, 06 March 2010, 13:10 GMT
As mentioned in the initial report, this is happening with an ext4 partition, with all the 'new stuff' which ext4 has to offer over ext3 enabled.
Comment by Thomas Bächler (brain0) - Wednesday, 09 June 2010, 17:48 GMT
This is a bug in fsck or e2fsck. The documentation states that 32 should be returned, and we test for that. A return value of 8 can mean anything and we can not blindly continue booting in this case.
Comment by Thomas Dziedzic (tomd123) - Sunday, 27 February 2011, 21:46 GMT
status?
Comment by Tom (hungerfish) - Monday, 28 February 2011, 11:06 GMT
I cannot seem to be able to reproduce the problem, mainly because just doing "touch /forcefsck" doesn't trigger the relevant script.
Where can I set 'nr. of mounts' so that I can get a 'real' forced-check on reboot?

Seeing that rc.sysinit has been changed though, I guess it may work now, although I'd like to test again...
Comment by Thomas Bächler (brain0) - Monday, 28 February 2011, 11:17 GMT
For the ext2/3/4 family of file systems, use tune2fs -c and/or -i to adjust the forced checks. I don't know what to do with other file systems.
Comment by Tom (hungerfish) - Monday, 28 February 2011, 16:02 GMT
I've tested again, and the issue has indeed been resolved :)
I set mounttimes to 40, got a forced check, cancelled it, bootup continued, rebooted, got the forced check again,let it complete, all things as they should be!
Comment by Thomas Bächler (brain0) - Monday, 28 February 2011, 16:17 GMT
Hopefully, this was just a (now fixed) bug in e2fsprogs. Closing, please reopen if this is indeed not solved.

Loading...