Comment 3 for bug 153310

I've run across this too. What I wanted was to set up every user's desktop to be like the 'oem' model, but I also wanted another user already installed by default. (In my particular case, I needed to have yours truly be able to access the box for customer support issues, so I wanted an "administrator" user who had sudo power.)

Here's how I worked around it:

After the "oem" user desktop was exactly like I wanted it,
[code]
# cp -R /home/oem /home/oem2
[/code]

Search-and-replace through /home/oem2, replacing every instance of '/home/oem' with '$HOME'. (There are half a dozen or so techniques for the forgoing: pick the one you like the most.)

[code]
# cp -R /home/oem2/* /home/skel
# rm -R /home/oem2
[/code]

Then made an ugly hack towards the end of the oem-firstboot script. I told oem-firstboot to run a tiny little bash script ("another-user.sh") I wrote and saved in /temp directory. another-user.sh was extremely simple: a one-line "adduser" command, using the command-line options to give the user name, what groups the user belongs to, password, etc. After another-user.sh runs (exit 0), processing goes back to oem-firstboot. The next line of oem-firstboot deleted another-user.sh. In the case I had, I knew the user wasn't going to be poking around in the scripts, so I wasn't worried about the security implications of having a password in a text file. (I told you it was an ugly hack.)

That's what worked for me, but the problem should of course be fixed the right way.

Happy Trails,

Loye Young