FS#12928 - [initscripts] kernel option "quiet" is being used to mute fsck output

Attached to Project: Arch Linux
Opened by Denis A. Altoe Falqueto (denisfalqueto) - Saturday, 24 January 2009, 11:12 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 June 2009, 14:02 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Description:

Hi,

As the summary says, the kernel option "quiet" is being used in /etc/rc.sysinit to discard the output of progress information of fsck, when it is run after n mounts of each filesystem.

In spite I can see the intention of that behaviour, I think that is not the common one. The "quiet" option should be used only for telling the kernel that you don't want all the information he spits out.

The corresponding commit to the file was this:

http://projects.archlinux.org/?p=initscripts.git;a=blob;f=rc.sysinit;hb=675e9d69d02233e0079672f6c10cbe07da3027ad

And this request was born from this discussion on arch-general:

http://www.archlinux.org/pipermail/arch-general/2009-January/003362.html

A well made remark from Markus Heuser was that the the progress information is not so verbose and is very unfrequent to be inconvenient.
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 07 June 2009, 14:02 GMT
Reason for closing:  Fixed
Comment by Greg (dolby) - Saturday, 24 January 2009, 17:41 GMT
Do you think that a progress bar adds anything? Despite being the "common behaviour" i dont see any advantages to it.
Comment by Xavier (shining) - Saturday, 24 January 2009, 17:50 GMT
I like the progress bar, and I don't like this strange and unexpected usage of the quiet kernel option, which is bound to create some confusion like it did in that discussion on arch-general, and will probably happen again.
Comment by Dan McGee (toofishes) - Saturday, 24 January 2009, 18:02 GMT
I've made this change manually before, and I've even seen Aaron tripped up by it for an hour trying to get his machine to boot. If you get to the point where an fsck is actually needed, I see very little reasoning to suppress the output in either the quiet or non-quiet case.
Comment by Aaron Griffin (phrakture) - Saturday, 24 January 2009, 23:07 GMT
So are we all for reverting this patch then?
Comment by Dan McGee (toofishes) - Sunday, 25 January 2009, 05:37 GMT
I'm for it, but obviously the first half of the patch only.
Comment by Markus Heuser (Vrob) - Sunday, 25 January 2009, 19:42 GMT
I definitly think the progress bar adds some convenience/functionality.
Since my box is equipped with a ~400 GB /home partition that takes like forever to be checked by fsck, I accidentily resetted my machine because I thought it had crashed.

I guess we all know the "let me just boot my pc for a second because I need to copy that file"-cases when fsck comes in and starts to look over your harddisk.
The status-quo is that we don't even get the "next check in X mounts"-warnings so that we can't even prepare.
Comment by Alessandro Doro (adoroo) - Friday, 13 February 2009, 18:06 GMT
Hi Markus,  FS#13157  fixes the "let me just boot my pc for a second because I need to copy that file" issue.
Comment by Markus Heuser (Vrob) - Saturday, 14 February 2009, 12:48 GMT
I've seen that bug report as well and definitly support it but I still think, that we should revert the suppression of all output in quiet mode.
As I already said, fscks out is not very much verbose and adds a quite some convenience (at least in my eyes).
Comment by Aaron Griffin (phrakture) - Monday, 16 February 2009, 18:06 GMT
The fsck handling has been changed in git, but the kernel "quiet" param is still used. Are we still interested in getting rid of that handling? It is a little odd, if you ask me
Comment by Aaron Griffin (phrakture) - Monday, 16 February 2009, 18:06 GMT
Reference:
if /bin/grep -qw quiet /proc/cmdline; then
FSCK_OUT=/dev/null
FSCK_ERR=/dev/null
else
FSCK_OUT=/dev/stdout
FSCK_ERR=/dev/null
fi
Comment by Denis A. Altoe Falqueto (denisfalqueto) - Monday, 16 February 2009, 18:34 GMT
IMHO, I think that there shouldn't be this handling.
Comment by michael (mike_93) - Tuesday, 03 March 2009, 13:41 GMT
I seriously thought that something had gone wrong with the booting process when it sat there saying [BUSY] on check filesystems and I definitely think that the progress bar should be included even with quiet
Comment by Aaron Griffin (phrakture) - Tuesday, 03 March 2009, 16:41 GMT
http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=666cd9b3971e171f4e8ec348666ab8ff8bfe97d8

Is this ok for you all?
Comment by Denis A. Altoe Falqueto (denisfalqueto) - Tuesday, 03 March 2009, 16:59 GMT
To me, it is fine.
Comment by Xavier (shining) - Tuesday, 03 March 2009, 17:09 GMT
I guess the variables FSCK_OUT and FSCK_ERR are no longer needed.
Is it needed to quiet the error output?
Why not just do : /sbin/fsck -A -T -C -a -t $NETFS $FORCEFSCK
Comment by Aaron Griffin (phrakture) - Tuesday, 03 March 2009, 17:14 GMT
Yeah, I wasn't too sure about that either, but wanted to leave them just in case.
Comment by Denis A. Altoe Falqueto (denisfalqueto) - Tuesday, 03 March 2009, 17:21 GMT
Maybe there could be some file in /etc/conf.d to configure this behaviour and use those variables. It doesn't meka much sense to me, but for the sake of configurability... I don't know. Maybe it's much effort for almost nothing.
Comment by Xavier (shining) - Tuesday, 03 March 2009, 17:23 GMT
I am pretty sure these FSCK_OUT and FSCK_ERR were added just because there were two cases, in order to factor them to only one fsck call :
http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=e932c3406acf105c99e159ca0610768fbfb49b1a

What I am less sure about is the 2>/dev/null part, which was added there with no explanation :
http://projects.archlinux.org/?p=initscripts.git;a=commit;h=ef6a41ebd7e2ab216e4b950df2a6d0826aef39b7
Comment by Petar Bogdanovic (pebo) - Tuesday, 31 March 2009, 14:38 GMT
> I am pretty sure these FSCK_OUT and FSCK_ERR were added just because there
> were two cases, in order to factor them to only one fsck call

Yes.

As it is right now, they can be safely removed/replaced. I do, however,
think that variables are a good thing. Like functions, they can make your
life easier.

Loading...