Unattended installation user data conflict

[Andrew Stoltz]

When passing user-data to the 20.04 unattended installation through an iso described at https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/QuickStart, user creation doesn't happen. This is because /dev/sr1 takes priority over /var/lib/cloud/seed/nocloud-net/.

The simple workaround for anyone experiencing this issue is to add the following to their user-data script:

  late-commands:
    - "eject /dev/sr1"

I experienced this using Hyper-V.

[Michael Hudson-Doyle (mwhudson)]

Ups, that's a bit messy. I'm not sure what we can do about this.

I have to say that I had expected that this would work by intercepting the reboot and disconnecting both the cidata drive and the install media before starting the VM again.

[Dimitri John Ledkov (xnox)]

Ouch

[Ryan Harper (raharper)]

@Andrew

Would you be able to run 'cloud-init collect-logs' and attach the tarball to this bug?

[Michael Hudson-Doyle (mwhudson)]

Here's some logs from a reproducer.

[Michael Hudson-Doyle (mwhudson)]

I had a bit of a think and a poke around and think I came up with a solution: https://github.com/CanonicalLtd/subiquity/pull/790

[Michael Hudson-Doyle (mwhudson)]

I tried my fix with the testcase from bug 1879485 and it worked, so that's a good start!

[Ryan Harper (raharper)]

Hrm, the cloud-init.tar.gz seems to have an empty /run ... I really wanted to see the /run/cloud-init/.ds-identify.result,ds-identify.log,cloud.cfg

[Michael Hudson-Doyle (mwhudson)]

On Tue, 16 Jun 2020 at 11:10, Ryan Harper <email address hidden>
wrote:

> Hrm, the cloud-init.tar.gz seems to have an empty /run ... I really
> wanted to see the /run/cloud-init/.ds-identify.result,ds-
> identify.log,cloud.cfg
>

Well I had to dig it out of a disk image because I couldn't log in to the
VM in this case... There are ways to make this possible I guess but a bit
tedious.

In any case, it's fairly clear what happens here when you read the source
for DataSourceNoCloud: filesystems with the relevant label are checked
after self.seed_dirs, and so any user-data there wins.

[Dan Watkins (oddbloke)]

OK, it sounds like cloud-init is behaving as we expect it to, so I'm going to mark our task as Invalid. Do comment (and change status to New, if you can) if you think that's incorrect.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3683