Ubuntu on EC2

Bug #1016695
Comment #4

Comment 4 for bug 1016695

Revision history for this message

Jeremiah Snapp (jeremiah.snapp) wrote on 2012-07-03: Re: add console=tty0 to cloud-image kernel boot parameters

Thanks Clint. I understand that we can't lose any messages going to the serial console. So I experimented and I have a different solution that I think would satisfy.

My main goal is to *by default* be able to see in the VMware console the kernel messages as well as the first few messages from cloud-init that show cloud-init is searching for the EC2 datasource by default and is timing out. Sending this info only to the serial port means anyone unfamiliar with running a cloud-image in VMware (or other hypervisor) may not understand that cloud-init is behind the scenes searching for the EC2 datasource and timing out. They would sit there wondering why it's taking so long to boot. *Maybe* they'd figure out they can add console=tty1 to their kernel boot parameters so they can see what is going on. I personally think Ubuntu server is great but this could be frustrating to others and potentially lead them to believe something just ain't right with Ubuntu servers.

My new solution is to add console=tty1 *before* console=ttyS0. Note that it's tty1 and not tty0.

This produces the same results as expected for the serial port. All messages are output to serial as usual.

This also outputs all kernel messages and just enough of the cloud-init messages to tty1 which makes it visible in VMware's vSphere console where you can watch it search for the EC2 datasource and timeout. The remainder of the cloud-init messages (including the cloud-init final message) are not visible in the console so you'd have to log in and check the cloud-init log in /var/log to see it's status but that's much better than nothing at all. When the server is done booting the VMware console displays the tty1 as expected which is why I used tty1 instead of tty0.

I tested all this by using VMware's ability to output serial port to a file.

I have attached a file for the serial port output for each of the following grub kernel parameter entries:

linux /boot/vmliuz-3.2.0-24-virtual root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0

linux /boot/vmliuz-3.2.0-24-virtual root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 ds=nocloud

The first shows cloud-init searching for EC2 datasource and timing out.

The second shows the results when cloud-init is configured with ds=nocloud.

Do you think this sounds reasonable?

Thanks Clint.  I understand that we can't lose any messages going to the serial console.  So I experimented and I have a different solution that I think would satisfy.

My main goal is to *by default* be able to see in the VMware console the kernel messages as well as the first few messages from cloud-init that show cloud-init is searching for the EC2 datasource by default and is timing out.  Sending this info only to the serial port means anyone unfamiliar with running a cloud-image in VMware (or other hypervisor) may not understand that cloud-init is behind the scenes searching for the EC2 datasource and timing out.  They would sit there wondering why it's taking so long to boot.   *Maybe* they'd figure out they can add console=tty1 to their kernel boot parameters so they can see what is going on.  I personally think Ubuntu server is great but this could be frustrating to others and potentially lead them to believe something just ain't right with Ubuntu servers.

My new solution is to add console=tty1 *before* console=ttyS0.  Note that it's tty1 and not tty0.

This produces the same results as expected for the serial port.  All messages are output to serial as usual.

This also outputs all kernel messages and just enough of the cloud-init messages to tty1 which makes it visible in VMware's vSphere console where you can watch it search for the EC2 datasource and timeout.  The remainder of the cloud-init messages (including the cloud-init final message) are not visible in the console so you'd have to log in and check the cloud-init log in /var/log to see it's status but that's much better than nothing at all.  When the server is done booting the VMware console displays the tty1 as expected which is why I used tty1 instead of tty0.