Date: Mon, 13 Sep 1999 06:01:11 -0500 (CDT) From: Mike Pritchard <mpp@FreeBSD.org> To: Doug@gorean.org (Doug) Cc: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes), des@flood.ping.uio.no (Dag-Erling Smorgrav), hackers@FreeBSD.ORG Subject: Re: How to prevent motd including os info Message-ID: <199909131101.GAA03636@mpp.pro-ns.net> In-Reply-To: <37DC7556.82A77322@gorean.org> from Doug at "Sep 12, 1999 08:53:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> "Rodney W. Grimes" wrote: > > > It dawned on me what can be done. Look, we get all the kernel printf's > > from the dmesg output saved in a buffer and pull that out later with > > syslog, looks like we could just slip a pipe fitting into /dev/console > > that copies all it's output into the mesgbuf as well, until we smack it > > wth the ballpean and tell it to stop doing that (Either getty lanching the > > login: on ttyv0 could cause this, or something at the end of /etc/rc). > > > > What do you think of that idea? > > I think that's a fine idea, and it's a lot cleaner than mine for a number > of reasons. Completely beyond me to code, but very nice from the design > standpoint. Most of the time I could care less what /etc/rc spits out. However, in the past, I have had to go add sleep(###) calls in various spots in rc to that I could actually read some of the error output to figure out why something was failing. I wouldn't mind having all of the /etc/rc output sent to the message buffer (and /dev/console) until a getty is running on ttyv0. Or at least make it a boot option. If you are having problems, boot the kernel with "boot -l" in the boot loader. Now, adding an option doesn't help in the case of fsck suddenly generating a million lines of output during boot, since that might not be expected, but it does help some cases. And scrollback buffers and message buffers only help if you have enough memory to hold all of that information. Right now I have 3 FreeBSD machine. 1 has 192MB of RAM. I have the message buffer set to some very large value (because of some boot problem I bumped it up a lot), so I at least see all of the kernel messages that were generating during a boot. This helped me debug a couple of problems. The other two machines only have 16MB, so they still run with a standard message buffer (geez, I remember when 16MB was *A LOT*). Perhaps we need a "boot message buffer" (just eat up free memory minus some protected space that is reserved for letting /etc/rc run without swapping). Keep sending data to that buffer during the boot process, and just before going multi-user, dump it off to disk and free it. On a 16MB machine, that shouldn't be a problem. For those people still running FreeBSD machines on 4MB, that is another story, but even in those cases, I would bet you could still be able to record and store at least some of the /etc/rc output. Its been a few years since I've seen fsck generate a couple of megabytes of output, so I know it is possible, but I think this idea could work, and solve most peoples problem of fsck generating MANY pages of output that just scroll by. -Mike -- Mike Pritchard mpp@FreeBSD.org or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909131101.GAA03636>