yahoo-eng-team team mailing list archive

[Paride Legovini <1961620@xxxxxxxxxxxxxxxxxx>]

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