[Touch-packages] [Bug 1359590] Re: Getty's on serial consoles need to be consistent
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2477 ** Bug watch added: github.com/canonical/cloud-init/issues #2477 https://github.com/canonical/cloud-init/issues/2477 ** Changed in: cloud-init Status: Confirmed => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1359590 Title: Getty's on serial consoles need to be consistent Status in cloud-init: Expired Status in util-linux package in Ubuntu: Confirmed Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1359590] Re: Getty's on serial consoles need to be consistent
One big thing to consider with this is that some clouds (i.e CloudSigma and Joyent) use a serial console as a meta-data channel. In at least one case, activating a getty on the meta-data channel tty will result in the instance being unbootable. For this reason, I think that baking them into the Cloud Images is probably a bad thing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1359590 Title: Getty's on serial consoles need to be consistent Status in Init scripts for use on cloud images: Confirmed Status in “util-linux” package in Ubuntu: Confirmed Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1359590] Re: Getty's on serial consoles need to be consistent
Not sure if this should also be tracked against the cloud image builder. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1359590 Title: Getty's on serial consoles need to be consistent Status in Init scripts for use on cloud images: New Status in “util-linux” package in Ubuntu: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1359590] Re: Getty's on serial consoles need to be consistent
** Changed in: cloud-init Status: New = Confirmed ** Changed in: cloud-init Importance: Undecided = Medium ** Changed in: util-linux (Ubuntu) Status: New = Confirmed ** Changed in: util-linux (Ubuntu) Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1359590 Title: Getty's on serial consoles need to be consistent Status in Init scripts for use on cloud images: Confirmed Status in “util-linux” package in Ubuntu: Confirmed Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
