Set the console kernel logging level

Alexander E. Patrakov patrakov at
Tue Apr 17 01:17:33 PDT 2007

Dan Nicholson wrote:
> On 4/16/07, DJ Lucas <dj at> wrote:
>> This is where the sysctl script should be run. /proc and /sys should be
>> available by that time.  It was moved a long time ago, memory is fuzzy
>> but I think it was due to a timing issue.  Anyway, it is designed
>> explicitly for this purpose.  Instead of adding scripts, how about this
>> (I think it's right):
>> ============================================
>> echo kernel.printk 4 >> /etc/sysctl.conf &&
>> mv /etc/rc.d/rc.sysinit/S90sysctl /etc/rc.d/rc.sysinit/S00sysctl
>> ============================================
>> Of course you can make the rest of the modifications if you like,
>> (kernel.printk 4 7 x x).  I don't recall sane values for the rest of
>> them or what they are for.  Also, please double check the syntax above
>> for the sysctl.conf file, I don't have a linux box handy ATM where I can
>> be exactly certain.
> I did not know that. The only problem with the sysctl script is that I
> don't think most people know how to use sysctl. This is a viable
> solution under one condition: sysctl needs to be documented in the
> book. The convenience of a wrapper script is that you can abstract the
> details.
> I don't really know the kernel-userspace interface enough to know when
> it's a safe time to start calling sysctl, but my feeling is that you
> can do it very early. So, we should consider moving that script up
> regardless of the outcome of this decision.

The problem is that some sysctls (e.g., the one for the maximum allowed RTC 
frequency settable by user) apply only after the corresponding modules are 
loaded. This usually means "after udev". But most of the kernel messages are 
printed while the udev bootscript works. Thus, -1 to the idea of reusing the 
existing sysctl script, +1 for the separate script that should run before udev.

But personally, I always just append the "quiet" parameter to the kernel 
line in the boot loader.

Alexander E. Patrakov

More information about the lfs-dev mailing list