Thanks for looking into this. I thought about pivoting into /target too,
that should save us from worrying about mounts at all, but requires
changes in how subiquity operates, and in general moves a bit away from
the idea that installs done from ISO should be treatable like cloud
instances, which is what allows us to use cloud-init on bare metal after
all. It a good guiding principle, as it helps convergence between bare
metal server systems and cloud instances.
On "not making cloud-init wait forever": I see your point, however in
the case of subiquity we're speaking of a freshly installed system,
which can't be in production. Between blocking boot and booting but
misconfiguring the system, I'm not sure the latter is better.
** Also affects: subiquity
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1961620
Title:
cloud-init can add users in wrong filesystem (race with `mount /home`)
Status in cloud-init:
Triaged
Status in subiquity:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1961620/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
