Comment 11 for bug 606373

On UEC instances, we boot with 'console=ttyS0'. On EC2 we boot with no 'console=' parameters. I believe that the hvc0 driver has somehow been modified so that it will get data written to /dev/console without any additional effort. I'm not sure of that, jjohansen would know more. One way or another, all "normal" messages ('echo HELLO WORLD | sudo tee /dev/console') correctly get to the ec2 console.

I enabled plymouth by adding '--attach-to-session --debug --debug-file=/var/log/plymouthd-debug.log' in /etc/init/plymouth.conf .

Looking in the output log, I see
EC2:
 [main.c] check_for_consoles:checking for consoles
 [main.c] check_for_consoles:There are currently 0 text displays
 [main.c] redirect_standard_io_to_device:redirecting stdio to /dev/tty7
 ..
 [main.c] check_for_consoles:There are currently 0 text displays

UEC:
 [main.c] check_for_consoles:checking for consoles
 [main.c] check_for_consoles:There are currently 0 text displays
 [main.c] redirect_standard_io_to_device:redirecting stdio to ttyS0
 ..
 [main.c] check_for_consoles:There are currently 1 text displays

I verified, that by adding 'console=hvc0' on ec2, all text correctly will correctly get to the EC2 console.

We do have the ability to boot UEC and EC2 images with different kernel command lines. On EC2 all our 10.10 images and later will be booted from pv-grub, and we generate/manage /boot/grub/menu.list via 'legacy-grub-ec2' package. On UEC, we can control the kernel command line in 1 of 2 situations (the case where we're booting with a grub loader, which only works on 10.10 hosts).

The point of the last paragraph, is that while I *can* change the kernel command line to have a specific console=XXXX at this point, I'd really rather not. Its somewhat happenstance that we could fix this bug. I would much rather be able to configure plymouth to write data to /dev/console just as it will write it to /dev/hvc0 if 'console=hvc0' is passed.