Bryan Kadzban wrote: > David Jensen wrote: >> Bryan Kadzban wrote: >>> Bruce Dubbs wrote: >>> >>>> To stop klogd from trying to read System.map, it requires passing -x >>>> in the command line. We can do that easily in the boot scripts. >>>> >>> Which I would suggest if we want to silence the warning. Given the >>> (total lack of) need for System.map for the past seven years, I think we >>> should also expunge any reference to it from the book, but whatever. >>> >>> >> from slackware rc.syslog >> # '-c 3' = display level 'error' or higher messages on console > > Starting to get off topic now, but after reading the klogd manpage, this > is exactly what the current LFS bootscripts do when you set LOGLEVEL in > /etc/sysconfig/console, and the /etc/rc.d/init.d/consolelog script runs: > > dmesg -n $LOGLEVEL > > So you could accomplish exactly this with the stock bootscripts, just by > setting LOGLEVEL=3 there; no change required to the klogd script. > > (Well, almost "exactly this". Setting the value to 3 doesn't display > "level 'error' or higher" on the console. 3 is KERN_ERR, but the kernel > displays only messages *worse* than the level you set. So you get > "levels higher than 'error'" on the console: KERN_CRIT, KERN_ALERT, and > KERN_EMERG. But that's the case with klogd as well; your comment > doesn't match the arguments given. :-) )
Its a learning situation for most of us. The section of the code in question uses LOG_ERR, LOG_WARNING, and LOG_INFO. For LFS, I don't think any kernel messages should be thrown out except maybe DEBUG when not trying to actively solve a problem. dmesg -n $LOGLEVEL only prevents logging to the console. "all levels of messages are still written to /proc/kmsg, so syslogd(8) can still be used to control exactly where kernel messages appear." I guess my point is not so much that I want to suppress the error message, but I want to control when the System.map is read which avoids the error (and the message). The easiest way to do that is to pass -x unconditionally. The most complete way is via a mechanism like the script I posted earlier. Another more difficult way would be to go back to syslog-ng. My first choice right now is the script with the unconditional -x as a second choice. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
