Getty's on serial consoles need to be consistent

This bug was originally filed in Launchpad as [LP: #1359590](https://bugs.launchpad.net/cloud-init/+bug/1359590)

Launchpad details

affected_projects = ['util-linux (Ubuntu)']

assignee = None

assignee_name = None

date_closed = None

date_created = 2014-08-21T07:47:01.408972+00:00

date_fix_committed = None

date_fix_released = None

id = 1359590

importance = medium

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1359590

milestone = None

owner = sabdfl

owner_name = Mark Shuttleworth

private = False

status = confirmed

submitter = sabdfl

submitter_name = Mark Shuttleworth

tags = []

duplicates = []

_Launchpad user **Mark Shuttleworth(sabdfl)** wrote on 2014-08-21T07:47:01.408972+00:00_

In our cloud images today we launch a getty on ttyS0, as long as it's not in a container. We don't launch a getty on ttyS1-n even if they exist.

In MAAS, which also uses cloud images, it would often be useful to put getty's on the serial port that is mapped to remote serial access, such as IPMI SOL. It is however difficult to know which is the correct getty.

Broadly speaking I think we should have a consistent approach to getty's. That might mean:

* launch a getty on each ttySn that passes an stty test (as per ttyS0 currently)
* allow cloud-init to prevent some of those, via vendordata or userdata or default behaviour per-cloud

or

* launch no getty's on ttyS, but
* allow cloud-init to create them based on vendordata or userdata or default behaviour per-cloud