Automated Install does not set default user data

[Dirk]

When I run the automated installer I always end up with a fresh system I cannot login to. The default user ubuntu has its password locked.

I tested this using the minimalistic example from the [wiki][1], latest Focal and virtualbox.

cat > user-data << 'EOF'
#cloud-config
autoinstall:
  version: 1
  identity:
    hostname: ubuntu-server
    password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
    username: ubuntu
EOF
touch meta-data

cloud-localds ~/seed.iso user-data meta-data

I tried to get in using these ways, too:

1. Adding a SSH key to an additional `ssh` section did not help as well.
2. Configuring a user in user-data did not work as well.

Actually, no settings from the `user-data` section work but configuration from the storage and network sections works like a charm.

[1]: https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/QuickStart#Using_another_volume_to_provide_the_autoinstall_config

[Michael Hudson-Doyle (mwhudson)]

This is very strange. Can you get /var/log/installer from the installed system somehow? (I guess you need to boot as single user to set the password for ubuntu first!) I guess /var/lib/cloud and /var/log/cloud-init* would be interesting too.

[Dirk (wedibit)]

I have attached all mentioned files. Just mounted the drive into another virtual machine. I can provide more if needed.

[Michael Hudson-Doyle (mwhudson)]

I think the mistake in subiquity is that subiquity generates this in the user-data:

  lock-passwd: false

but cloud-init looks for "lock_passwd". But now I don't understand how this ever works, i.e. why all users created by subiquity do not get their accounts locked.

[Dirk (wedibit)]

I tried to work around this bug by preconfiguring everything but ask for the user. This does not work as well.

#cloud-config
autoinstall:
  version: 1
  interactive-sections:
    - identity
  identity:
    hostname: ubuntu-server
    password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
    username: ubuntu

Then I tried to work around this bug by creating a user using user-data but this does not work as well. After installation, there is no user 'testuser', just a deactivated 'ubuntu' user.

#cloud-config
autoinstall:
  version: 1
  identity:
    hostname: ubuntu-server
    password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
    username: ubuntu
  user-data:
    timezone: Europe/Berlin
    users:
      - name: testuser
        password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
        lock_passwd: false
        groups: users, adm

In addition, the seed configuration yaml is not recognized when it's not prepended with '#cloud-config' (n.b. a random comment or yaml node might be sufficient as well, I haven't tested these cases). I guess this is another bug?

[Dirk (wedibit)]

Looks like this bug affects the NoCloud provider with a seed file system. It does work well when downloading the config with nocloud-net.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Hudson-Doyle (mwhudson)]

I've committed the fix that sets the lock_passwd key instead of the lock-passwd key, so if you can test with:

refresh-installer:
    channel: edge
    update: yes

in your config, I would appreciate it.

I still don't understand at all why nocloud vs nocloud-net makes a difference. It really shouldn't!

[Dirk (wedibit)]

Unfortunately, I still cannot login after running the installer.

You can replicate what I did with Virtualbox using this script: https://gist.github.com/wedi/cba7465ee8280c0e75f94d2ef024a82e
Probably you'll need to switch from Apple's hdiutil to cloud-localds or similar to create the seed image.

[Michael Hudson-Doyle (mwhudson)]

Hi, thanks for the reproduction script. This turns out to be the same as this bug https://bugs.launchpad.net/subiquity/+bug/1879103.