shadow passwords not enabled (no rootpw)

I think I may have fixed this in an earlier dapper-updates upload:

kickseed (0.35.1) dapper-updates; urgency=low

  * Fix passwd/root-login preseeding (closes: Malone #48038).

 -- Colin Watson <email address hidden> Mon, 5 Jun 2006 02:22:10 +0100

I'm assuming you're running Dapper? If so, could you try adding 'preseed passwd/root-login boolean false' to your Kickstart file for now and see if it works around your problem?

Yes, we are running dapper.

I added that line below the above and the installer stopped and asked me for a name for the first user account. Placing it above the 3 lines has the same effect as leaving it out.

Oh, buggeration, right, I misread your preseed file and I've just noticed another problem in the code ...

Try 'preseed passwd/root-login boolean true' instead.

That makes more sense now. However, it still had the same results with no /etc/shadow created. Is it supposed to matter what order the auth, user, rootpw and preseed lines are in?

This seems a lot worse to me than "low urgency" if kickstart is supposed to be a supported method of installing. Should we be running `shadowconfig on` in the postinstall or something? This was working previously with dapper, from looking back at logs it appears to have been in the march/april range.

What's the story on this? Did this get fixed and the bug simply forgotten?

For the record, we do run shadowconfig on if passwd/shadow is true, which is (a) the default and (b) preseeded by this Kickstart file. I think it must be something a little less obvious.

Matt: ordering of different commands is not important in Kickstart files. (Ordering of the same command, for example multiple 'part' commands, may be relevant.)

The only difference between test-kickseed output for dapper and dapper-updates is:

-d-i passwd/root-login true
+d-i passwd/root-login boolean true

It seems unlikely that the old output would cause shadow passwords to be disabled, but I'll check it.

Our user configuration for Kickstart is as follows:

# config section
auth --useshadow --enablemd5
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
user nttuser --fullname "xxxx user" --iscrypted --password xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And we don't notice any problems with the creation of the shadow file. Perhaps this is now fixed?

I work with matt (the original reporter) and it is still not working for us. We got around it for a while with some sed magic.

Our user config section looks like:

rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
user --disabled
auth --useshadow --enablemd5 --enablenis --nisdomain ournisdomain --nisserver ournisserver

A shadow file is created with no root password (root:x:...)