Linux Bootup Screens
Hi there I've just reinstalled my system on a softraid1 on two Seagate Cheetahs (36GB ST336607LW 68Pin Ultra320 SCSI) connected to an LSI21320-R. When booting up the controller's bios reports that the devices...
The oldest Unix email I know of used this syntax to send mail: but it actually invokes "sendmail" to do the delivery. Configuring sendmail is **dificult**. Postfix is somewhat easier. Most systems come with...
A smarthost is probably what the OP needs, but it doesn't require a 'big' mailer like sendmail postfix exim. A simple mailer such as ssmtp would do...
It applies, that you can press Ctrl-Alt-F1 or F2... to get a virtual console. The X session takes one of them, number 7 on my distro.
What sometimes fails here is that some (most?) distros have also a login program running in the virtual terminal, and that program blanks the screen and puts out a banner text ("Fedora Core 4...") and a login prompt. All those last lines are gone.
The boot screen messages fall in three categories:
1. Those output by the various Bios components, and the boot loader, before the kernel is loaded and started. 2. Kernel messages. 3. Userland program messages.
When the kernel has finished "discovering" all the buses and devices, it starts the program "init", which in turn starts everything else. At that point the kernel does not generate so many messages, and those it generates are generally side effects of something a userland program did, or some exceptional hardware event.
The kernel messages are kept in a ring buffer. That means, a fixed size memory buffer, where old messages are deleted to make room for new ones. However, the buffer is usually several times bigger that required to hold the boot-time probing messages.
The command "dmesg" dumps the contents of the kernel ring buffer. You can do this repeatedly, ie. the messages don't get deleted just because you dumped them.
Actually, many (maybe most) domains do accept email via SMTP directly from any host, as SMTP was intended to do. There are a number...
I am planning to set up a system to learn and practise developing device drivers. For this, I am planning...
The userland programs started by Init are less predictable, anyone can configure anything. However, the package sysvinit which comes with most distros, have a bunch of boot-time scripts, among them rc.sysinit. Rc.sysinit is often heavily cusomized by the distros, but it is common that it dumps the contents of the kernel ring buffer to a file invar-log. In my distro, the file is calledvar-log-dmesg. Kernel messages happening after this, are not in this file.
Other boot-time scripts starts the prgrams klogd and syslogd. Syslogd listens on a named pipe. and receives connections from other programs, and logs all messages those programs send it. Klogd first dumps all the kernel messages to syslog, then monitors the ring buffer to dump and new messages too. This gives me a third place where I can find the kernel messages, invar-log-messages, which is the main log file on my system. However, syslog is very customizable, you can have syslog to filter the messages according to severity and place them in separate files, or discard some categories.
The third category of messages, those generated from the userland programs, as long as we are talking about sysvinit scripts, are logged through syslog. However, the earliest of these messages are not logged, because syslog has not yet started. This applies to all messages from rc.sysinit on my system.
Perhaps not quite all bootscript messages are logged through syslog. The regular sysvinit scripts do, but programs started by them may output things on the screen and not in to syslog. The sysvinit scripts do not capture all screen output, they use functions that output everything twice, once to the screen and once to syslog. The colored OK part of the messages are not sent to syslog.
-Enrique