Re: Linux Boot-up Screens



Enrique Perez-Terron wrote:
> > On Mon, 02 Jan 2006 19:02:36 +0100, iforone <floydstestemail@xxxxxxxxx> wrote:

> > hi all;
> > my 2 cents
> > i'm new to using linux, so what I'm saying below may not be *correct* -
> > but i've booted to knoppix 3.6 (using 2.4 and 2.6 kernels) in the past,
> > and noticed that after the system starts X11 (or X Windows) and enters
> > the GUI mode -- if i desire to see the whole last Boot screen text i
> > merely hit CTRL+ALT+F1 (F1-F7) to drop to root - and ALT+F7 (or ALT+F5)
> > to return to X.
> >
> > This doesn't show you ALL the info that bootup created, but shows you a
> > good last chunk of the last boot screen - and I'm sure this is not the
> > *correct* way to do this, but it helped me out at one point.
> >
> > any thoughts about this ? Does this normally apply to most distros that
> > are installed to the HDD ?
>
> 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.

"virtual console" ? ....hmmm - ok,

> 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.

in knoppix 3.6 - this is not the case (LiveCD boot - saved
config)....note knoppix is up to 4.0.2 atleast at this point and
knoppix 3.6 contained, at that time, an 'experimental' version of the
2.6 kernel - naturally, also a stable 2.4 version...which didn't fair
too well with some older intel + oem hardware (circa 1999).

> 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.
>
> 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 in
> /var/log. In my distro, the file is called /var/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, in /var/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

Thank you Enrique, for the comprehensive reply...
i will absorb the info as time allows :-)

.



Relevant Pages

  • Re: [PATCH 00/23] per device dirty throttling -v8
    ... an XT when copying large files" bugzilla entry: ... start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM box, ... I've got a syslog server that's got two Opteron 246 cpu's, 16G ram, 2x140G ...
    (Linux-Kernel)
  • Re: [PATCH 00/23] per device dirty throttling -v8
    ... start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM box, ... I've got a syslog server that's got two Opteron 246 cpu's, 16G ram, 2x140G ... cron job copies the data to the raid array. ...
    (Linux-Kernel)
  • [2.6.18-rc7] printk output delay in syslog wrt dmesg still unfixed
    ... which I reported for kernel 2.6.18-rc1 on my ... output from printkappears in syslog (eg. ...
    (Linux-Kernel)
  • Re: [PATCH 00/23] per device dirty throttling -v8
    ... start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM box, ... I've got a syslog server that's got two Opteron 246 cpu's, 16G ram, 2x140G ... I have syslog doing buffered writes to the SCSI drives and every 5 min a cron job copies the data to the raid array. ... I've experimented with nice levels (nicing down the grep and nicing up the syslogd) without a noticable effect on the losses. ...
    (Linux-Kernel)