FS#13157 - /etc/rc.sysinit should distinguish between a cancelled and a failed fsck(8)

Attached to Project: Arch Linux
Opened by Petar Bogdanovic (pebo) - Sunday, 08 February 2009, 12:12 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 20 February 2009, 00:18 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Just because $fsckret is greater than 1 doesn't mean that fsck failed.
I just missed my train because I quickly needed that one file and there
was no way to cancel fsck without rebooting the system or falling back
into a limited root shell.

From man fsck:

``32 - Fsck canceled by user request''


So if $fsckret is 32, let me boot..
This task depends upon

Closed by  Aaron Griffin (phrakture)
Friday, 20 February 2009, 00:18 GMT
Reason for closing:  Implemented
Additional comments about closing:  In git
Comment by Alessandro Doro (adoroo) - Sunday, 08 February 2009, 14:20 GMT
rc.sysinit is doing the right thing. The file system must be in a clean state in order to run.
If it was the periodic check you could disable it with tune2fs (see options -c and -i).
Comment by Petar Bogdanovic (pebo) - Sunday, 08 February 2009, 15:42 GMT
I don't want to disable the periodic check. I just want to be able to interrupt it whenever I think it's necessary. rc.sysinit still may bail out upon any other return value besides 1 or 32. There is no need for patronizing people here.
Comment by Petar Bogdanovic (pebo) - Monday, 09 February 2009, 11:30 GMT
Patch attached.
   rc.sysinit.diff (0.3 KiB)
Comment by Aaron Griffin (phrakture) - Monday, 09 February 2009, 16:54 GMT
The thing I don't like about this... if you cancel the fsck, the system could be screwed and we're going to boot as if nothing happened.

If you cancel it this way, does it at least re-fsck on the next boot?
Comment by Alessandro Doro (adoroo) - Monday, 09 February 2009, 17:15 GMT
Yes. Mount count is not reset.
Comment by Petar Bogdanovic (pebo) - Monday, 09 February 2009, 17:21 GMT
> if you cancel the fsck, the system could be screwed and we're going to boot as if nothing happened

That should not be a problem if the fs has a journal since the journal usually gets replayed before fsck. If there is no journal, rw-mounting a somehow damaged fs could do some more harm I guess..


> If you cancel it this way, does it at least re-fsck on the next boot?

Yes.
Comment by Aaron Griffin (phrakture) - Monday, 09 February 2009, 17:34 GMT
Hmm, can you modify the patch so it still at least calls stat_fail if interrupted by the user?
Comment by Thomas Bächler (brain0) - Monday, 09 February 2009, 20:20 GMT
That patch is wrong anyway. I guess we can add this, with the stat_fail included.
Comment by Aaron Griffin (phrakture) - Monday, 09 February 2009, 20:29 GMT
Thomas, you got this one, or do you want me to push it?
Comment by Petar Bogdanovic (pebo) - Monday, 09 February 2009, 20:32 GMT
> That patch is wrong anyway.

Yup, sorry. Had no arch to test it.


> I guess we can add this, with the stat_fail included.

I'm rewriting this rc.sysinit part as we speak but if someone else already did it, let me know..
Comment by Petar Bogdanovic (pebo) - Monday, 09 February 2009, 22:52 GMT
I had to move the reboot code into an own function in order to avoid silly intendation levels.

Merged view: http://smokva.net/arch/rc.sysinit
   rc.sysinit.diff (3.3 KiB)
Comment by Petar Bogdanovic (pebo) - Monday, 09 February 2009, 23:05 GMT
Of course I meant ``indentation levels''.
Comment by Thomas Bächler (brain0) - Tuesday, 10 February 2009, 00:35 GMT
Looks good, can you make this a diff against http://projects.archlinux.org/?p=initscripts.git;a=summary
Comment by Petar Bogdanovic (pebo) - Tuesday, 10 February 2009, 12:39 GMT
No fuzz after applying on the top of 2c5e306 (Adjust copyright year to 2009).
Comment by Aaron Griffin (phrakture) - Tuesday, 10 February 2009, 16:29 GMT
pushed
http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=e932c3406acf105c99e159ca0610768fbfb49b1a
Comment by Alessandro Doro (adoroo) - Tuesday, 10 February 2009, 16:48 GMT
Ok, right step against Murphy's law. Everytime one's is in a hurry fsck goes in his way, really.
Hoping users don't abuse it.
Comment by Aaron Griffin (phrakture) - Tuesday, 10 February 2009, 18:44 GMT
Well, think about it this way - even right now a user can cancel the fsck. The machine just reboots when you do that. To me, that seems more like an annoyance. My computer should Do What I Tell It To Do(TM)
Comment by Alessandro Doro (adoroo) - Tuesday, 10 February 2009, 19:35 GMT
I'm not trolling and agree with you (I own a not-yet-dismissed machine with an ext2 file system and the check is really a pain). The commit is *really* desired.
My only concern is about _possible_ abuses.
Every Windows user I know indefinitely aborts the file system check triggered by power failure or system block. Anyway, they should do what they want with their machines.
And if an uneducated linux user wish to indefinitely abort the periodic fsck I'm sure will find the way to disable it.
So +1 from me.
Comment by Aaron Griffin (phrakture) - Tuesday, 10 February 2009, 19:47 GMT
For the record: I didn't even know you could abort the fsck until this bug report :)

Loading...