preseed install fails with "The username you entered (root) is reserved.."

Preseed used for the install. I'm quite sure it can be reproduced with much simpler one.

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

i think you are missing a line like:

d-i user-setup/allow-password-weak boolean true
("ubuntu" isnt a very strong one) ....

the error message should indeed tell you instead of pointing to the root user ...

Is that something new? This preseed used to work for months.

The same error with "d-i user-setup/allow-password-weak boolean true" in preseed :-/

Although I cannot confirm that it is or isn't the case, jenkins is one of the user names "reserved" to be used by the jenkins package (it creates a system user call jekins in it's post-install). Thus preseeding user-name jenkins is dangerous, if jenkins package is later installed or is going to be installed. Preseeding "butler" or "jenkinspreseeduser" would be better.

So, um, silly question but where are you actually applying this preseed file? I don't see anything relevant on the kernel command line; the closest is ks=http://10.128.92.2/cblr/svc/op/ks/system/dx-autopilot-intel, but since Kickstart is only supported by d-i-based images that isn't going to work here.

Its being managed by Utah. I actually don't know the details. Will ping somebody on IRC to answer your question, Colin.

Dmitrijs: While I tend to agree, that isn't the direct cause of this problem because the preseeded username simply isn't being applied at all.

The preseed is packed into the initrd by utah. For d-i images, putting preseed.cfg at the root of the initrd seems to do the trick. For casper/ubiquity, we use a casper-bottom script to copy preseed.cfg into the root of the live filesystem before pivoting into it. I can get you more details if necessary, but as Martin indicated, we've been using this technique for a while now without issue. Additionally, I'm using a preseed with a slightly stronger password that's still having the problem, if that makes a difference.

Whatever it is, it apparently isn't working any more. Perhaps somebody could post /var/log/casper.log?

Incidentally, casper has built-in code to load /preseed.cfg from the initramfs.

In fact, the next helpful thing to do would be to add DEBCONF_DEBUG=developer to the kernel command line and then extract /var/log/casper.log after boot.

I'll try to recreate this with that option on. The same issue is affecting debian-installer based images, so I'm inclined to think it's something outside of casper, and possibly outside of ubiquity as well.

This is the casper-bottom script we run to insert the preseed and the rsyslog configuration into the live filesystem.

This is the rsyslog script referenced in the previous script. {{dest}} is filled in with an rsyslog host or serial connection configured by the installer.

The preseed file on the d-i test system I looked at said "d-i passwd/username string root" - so this looks like either a utah bug or an incorrect utah setup.

utah gets the username to run a job as from getpass.getuser(). This previously returned jenkins, but recently it started returning root because LOGUSER in jenkins is set to root now. We're still trying to figure out why that change happened, but we've applied a configuration file to the jenkins user in ~/.utah/conf.d/jenkins-user that contains:
{
    "user": "jenkins"
}
This will use the jenkins user for all jobs unless another user is specifically requested.