cloud-init can add users in wrong filesystem (race with `mount /home`)

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

Launchpad details

affected_projects = ['subiquity']

assignee = None

assignee_name = None

date_closed = None

date_created = 2022-02-21T17:53:53.146797+00:00

date_fix_committed = None

date_fix_released = None

id = 1961620

importance = high

is_complete = False

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

milestone = None

owner = paride

owner_name = Paride Legovini

private = False

status = triaged

submitter = paride

submitter_name = Paride Legovini

tags = ['iso-testing']

duplicates = []

_Launchpad user **Paride Legovini(paride)** wrote on 2022-02-21T17:53:53.146797+00:00_

When cloud-init is used to configure a new Ubuntu Server system installed from the ISO images, and /home is configured as a separate partition, there is a (slow) race between the user creation and /home being mounted. This can lead to the user $HOME being created in the wrong filesystem.

Steps to reproduce:

1. Prepare to install focal-live-server-amd64.iso in a VM.
In my case I used one of the 20.04.4 dailies.

2. Proceed with all-defaults but for storage. Configure the storage
so / is in a dedicated partition, while /home in a an *encrypted*
LVM volume. (The only purpose of encryption is to add delay in the
/home mount, see the next point.)

3. Finish the install and reboot. At the dm-crypt password prompt
stop and wait a few minutes. At some point cloud-init will proceed
creating the configured username, but /home is not mounted yet!
The user's $HOME is now in the same filesystem as /.

4. Enter the dm-crypt password. This will cause /home to be mounted
from the encrypted volume, and this will shadow the actual $HOME.

5. Login with the configured credentials and verify that $HOME is
inaccessible.