getty.target starts before cloud-config is done

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1861128

Launchpad details

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = None
date_created = 2020-01-28T14:55:33.117913+00:00
date_fix_committed = None
date_fix_released = None
id = 1861128
importance = high
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1861128
milestone = None
owner = falcojr
owner_name = James Falcon
private = False
status = triaged
submitter = xnox
submitter_name = Dimitri John Ledkov
tags = []
duplicates = []

Launchpad user Dimitri John Ledkov(xnox) wrote on 2020-01-28T14:55:33.117913+00:00

On targets that are normally accessed via serial console (i.e. Subiquity, Ubuntu Classic/Core on RPi, etc) cloud-init often does not complete before getty spawns login shell.

This creates subpar user experience, as it appears as if one can login, and should be able to login using cloud-init provided credentials, but in practice cannot.

To mitigate this we have started to add the following override on some of our images:

See: http://launchpadlibrarian.net/461986467/livecd-rootfs_2.636_2.637.diff.gz

• mkdir -p /etc/systemd/system/cloud-config.service.d
• cat << EOF > /etc/systemd/system/cloud-config.service.d/getty-wait.conf +# Wait for cloud-init to finish (creating users, etc.) before running getty

• +[Unit] +Before=getty.target +EOF

Instead, cloud-config.service itself should declare Before=getty.target

Use case is monitoring RPi booting on serial console, and loging in once getty is up. With expectation that login succeeds.

Currently login fails, more cloud-config spew appears on screen, then one has to hit enter to realise that login is up, realize that one is now trying to login with empty username, hit enter again, and now type in username & password to finally login.

[ubuntu-server-builder]

Launchpad user Ryan Harper(raharper) wrote on 2020-01-29T22:04:56.201726+00:00

While the user is created earlier, other modules such as:

locale, set-password, and ssh-import-id should be run before getty.target for login to be successful.

So I think this is the right change for now; however, if the image also were to need to seed snaps, we're also then blocking login until after snaps have seeded as well.

[ubuntu-server-builder]

Launchpad user Dave Jones(waveform) wrote on 2022-05-06T14:10:43.870902+00:00

I don't think there's a sensible way of fixing this:

Ideally we'd have getty wait until users exist but there's no trigger / phase of cloud-init that's specific to it creating users. We could wait until cloud-init is "done" but in the case of more complex cloud-init configurations that could be an entirely arbitrary (even infinite) delay (waiting for network connections or arbitrary scripts to finish). Meanwhile, the user creation could be complete, but the admin is unable to login to the system to sort out networking (for example) because cloud-init hasn't "finished".

I looked into the possibility of adding conditions (and some extra activation triggers) on getty to cause it to wait until a (non-root) local user appeared in passwd/shadow but this then breaks the scenario where cloud-init is configured not to create any local users because (for example) LDAP is going to be used.

I'm leaning towards closing this as "won't fix" at this point, although first I would at least like to look into a first-time boot message warning the user they should wait for cloud-init to complete.

[holmanb]

Cloud-init ensures that user creation etc happens before systemd-user-sessions.service. I'm not convinced that blocking tty spawning should be a decision opinionated by cloud-init - this seems like more of a distro decision. A generic fix for this would be to make getty.target After=systemd-user-sessions.service, but since that is outside of cloud-init's perview I'm going to close this as "won't fix".