[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bootlogd



Calamine wrote:

> On Mon, 31 Oct 2011 10:46:55 +0000, Bob Brewer wrote:
> 
>> Calamine wrote:
>> 
>>> Yes, and that sounds even weirder, I mean, that can be launched on a
>>> running system but fails when loading. I've also found another bug
>>> report (which is older than the one you pointed before) that
>>> basically comes to say the same as you:
>>> 
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564149
>>> 
>>> And I'm afraid I'm now out of ideas. Let's see if someone else can
>>> give you additional advice on how to debug this problem :-)
>> 
>> Unfortunately my logs don't go back far enough to see what was
>> changed when the problem first started. This PC is nearly 10 years
>> old and its con fig hasn't been changed since the problem first
>> started, so I think I should be able to rule out a hardware related
>> issue.
> 
> The above bug (564149) and the brief note in the bootlog script
> itself (advising that sometimes does not work) makes me wonder if this
> can be a commom problem affecting other users :-?
> 

I think you are right. After I posted earlier I found a recent update to 
this bug (#423528) dated 11 August and included a patch to remove the  
'-c'option, and the latest update (dated 9 October) to #545181 will 
split bootlog  out of the sysvinit-utils package altogether. I can't see 
anything in the repositories to reflect this yet though.

> True is that it has always worked for me and I have Debian installed
> in servers, workstations, desktops and netbook systems with a mix of
> Lennys (GRUB legacy) and Wheezys (GRUB 2) and under different
> filesystems (ReiserFS and Ext4).
> 
> The only common characteristic they all share is that there are no
> "/var" partitions.
> 

Its' always worked for me in the past when I have been running sid on 
this box and is working fine on my Lenny server where /var is also on a 
separate partition as well (and also booting with lilo).


>> I have now had a look at /etc/rc2.d and see that bootlog isn't
>> started by sysvinit-utils and only 'S20stop-bootlog' is linked which
>> stops bootlog at boot completion.
> 
> Yes, I also noticed that.
> 
> This bootlog facility is something new to me since I started using it
> in Debian, but I don't remember a similar tool in openSUSE (maybe is I
> just overlooked it). In openSUSE the booting sequence was also logged
> under "/ var/log/boot.msg" but it is enabled by default and both
> (kernel and booting services messages) fall here, in the same file.
>
I first started running Woody Debian and Red Hat before that and can 
only remember logging to /var/log/boot. I don't remember problems before 
now though.

>> If I add a link to bootlog with 'S07bootlogd' it mysteriously gets
>> changed to 'S04bootlogd' after startup and I then see the 'Starting
>> Bootlogd - Bootlog failed' error messages in the console at startup.
> 
> You only have to care that "bootlog" is started after
> "mountdevsubfs".
> 
> What's the output of "ls -l /etc/rcS.d"?
>  

I was looking at runlevel 2 (rc2.d) and can see now see a link in rcS.d 
to bootlog at the beginning and to stop-bootlog-single at the end so I 
expect this is how the bootlogger is started. Comparing that to my Lenny 
box it is very similar.

>> My guess is that a process other than sysvinit is supposed to start
>> the bootlogger. I still use lilo as a boot loader and I presume that
>> your Wheezy starts with grub, so I wonder if this a lilo/grub issue?
> 
> I think the bootloader has nothing to do here because the bootloader
> is only in charge of passing the required parameters to the system.
> And the fact that "bootlog" wants to start but then fails makes me
> think the init script is being executed but aborts.
> 
 On reflection that seems to be correct. I'll try removing the '-c' 
option and see if that helps otherwise I'll wait a week or so to see if 
there are any updated packages in line with the bug reports above and 
try those.


Thank you for help, it's much appreciated


Bob


Reply to: