[RE: Problem with initial boot]

Bill Maltby - LFS Related lfsbill at wlmcs.com
Wed Jan 1 06:41:55 PST 2003


On Wed, 1 Jan 2003, Farley Benn wrote:

>In article <Pine.LNX.4.21.0212311949480.14524-100000 at wlmcs.wlmcs.com>, Bill Maltby - LFS Related wrote:
>> On Wed, 1 Jan 2003, Farley Benn wrote:
>> 
>>>In article <522HaaaCl4304S18.1041380917 at uwdvg018.cms.usa.net>, Eric Miller wrote:
>>>> So, what is the verdict here?[...]

>>>> The program helps users to print  out  their  bootup  mes-
>>>>        sages.   Instead of copying the messages by hand, the user
>>>>        need only:
>>>>               dmesg > boot.messages
>>>>        and mail the boot.messages file to whoever can debug their
>>>>        problem
>>>> 
>>>> Any feedback?
>>>> 
>>>
>>>On my host system, dmesg gives only a part of the boot-time messages.
>>>
>>>I have tried everything I know to get a full copy of them, with no success.
>> 
>> That's because it is a limited size "ring buffer". If you can issue the
>> command early enough, you see the early part, but lose the end. If you
>> then issue it again later, you see the end, but not the first.
>> 
>> So, an early dmesg >/var/log/boot_part_1 (for example) and a second one
>> issued later in the process like dmesg >/var/log/boot_part_2 might work?
>> Never tried this - I start it to a virtual terminal and that has done it
>> for me (haven't had to mail stuff off).
>> 
>> BTW, if you use the vt method, have your rc script switch vt to show the
>> one of interest.
>> 
>>>
>>>Farley
>>>
>> 
>
>Hey Bill,
>
>	I don't get that at all. How am I supposed to "issue the command
>early enough in the process" when the filesystem has not even been mounted
>then?

Correct. But the ring buffer should not overflow before /root mounted and
virtual terminals are available. So, in essence, if the boot process
progresses to the point that it can find /etc/rc.d/init.d/rc, you should
be able to start dmesg to a virtual terminal from that script.

/etc/rc.d/rcsysinit.d/S30checkfs remounts / read-only to run fsck. You
*can* (but I would recommend *against*) dump dmesg to disk prior to that.
For me, I would change (among other things) the fsck that it runs to
*only* check / and get it remounted read-write asap right within that
script. This involves changing parameters to the fsck (the usual "man
fsck" here). At that point, preferably in an S32* script, dmesg can be
dumped to somewhere on the root file system. Then add a S34* script that
checks the rest of the FSs (-P to fsck to avoid trying to check root?) and
S40* is changed to *not* mount the root.

One last thing, IIRC, not *all* messages seen in sys/kern.log will appear
in the ring buffer. At some point in the kernel initialization and
subsequent actions process, things should stop going to that buffer unless
something exceptional happens. So, effectively, you never see the end of
it, but it is "at the end" at that time.

>Farley

>> -- 
>> Bill Maltby
>> lfsbill at wlmcs.com
>> 

HTH

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message



More information about the lfs-support mailing list