The kernel actually does a good job of handling multiple 'console=' items. It then writes the same data to each of them (if they're valid devices).
However, when init (upstart) takes over, it only writes to /dev/console. So whatever the /dev/console means to the kernel is the only place that output from upstart or it subprocesses will go.
I think the kernel picks the last of the 'console=' items on the command line to tie to /dev/console. It may take the last *valid* entry, i'm not sure.
So, when upstart starts, and then starts running jobs (such as cloud-init) their output goes to /dev/console, and not to the other 'console=' places specified on the command line.
What all that means, is that I think we can fairly harmlessly add additional 'console=' lines to the command line, and have kernel messages go there. However, upstart messages will *not* go to those places.
The kernel actually does a good job of handling multiple 'console=' items. It then writes the same data to each of them (if they're valid devices).
However, when init (upstart) takes over, it only writes to /dev/console. So whatever the /dev/console means to the kernel is the only place that output from upstart or it subprocesses will go.
I think the kernel picks the last of the 'console=' items on the command line to tie to /dev/console. It may take the last *valid* entry, i'm not sure.
So, when upstart starts, and then starts running jobs (such as cloud-init) their output goes to /dev/console, and not to the other 'console=' places specified on the command line.
What all that means, is that I think we can fairly harmlessly add additional 'console=' lines to the command line, and have kernel messages go there. However, upstart messages will *not* go to those places.