> I think there is a good reason that they are not using bootlogd by
> default. I think I read somewhere that bootlogd is quite buggy on some
> systems, and it is hard to make it work correctly the way it is
> designed. So the proper fix in the long run would be to redesign it
> completely, as Scott is intending to do with logd in the future. I don't
> remember where I read this however... Probably tekknokrat ran into one
> of those problems.
No, that error (cannot find console device 136:1) means that bootlogd
was run from a terminal emulator (xterm or screen or mc or ... ).
It must be run from a real console device.
Passing console=/dev/console to the kernel is an error. I think the correct
value is /dev/tty0 or /dev/tty1. And bootlogd will use something like this
anyway.
I have another problem with bootlogd. It gets confused by terminal
control codes (those that make screen output prettier). I'll try to look
at the source and see what can be done.
> I think there is a good reason that they are not using bootlogd by
> default. I think I read somewhere that bootlogd is quite buggy on some
> systems, and it is hard to make it work correctly the way it is
> designed. So the proper fix in the long run would be to redesign it
> completely, as Scott is intending to do with logd in the future. I don't
> remember where I read this however... Probably tekknokrat ran into one
> of those problems.
No, that error (cannot find console device 136:1) means that bootlogd
was run from a terminal emulator (xterm or screen or mc or ... ).
It must be run from a real console device.
Passing console= /dev/console to the kernel is an error. I think the correct
value is /dev/tty0 or /dev/tty1. And bootlogd will use something like this
anyway.
I have another problem with bootlogd. It gets confused by terminal
control codes (those that make screen output prettier). I'll try to look
at the source and see what can be done.