[ Thread Index |
Date Index
| More lists.tuxfamily.org/slitaz Archives
]
- To: slitaz@xxxxxxxxxxxxxxxxxxx
- Subject: tazx problem
- From: Indigo <pointofavailability@xxxxxxxxx>
- Date: Fri, 5 Nov 2010 14:47:21 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=1MrBzqPasWBoooscKeamvavtjVaRokzqU1nNCZUqOb0=; b=WfmMAvB8fyYK+ButzFw/vJjLh/B2anfDVUTEgv+89FnXmY9EmRJAE6xcd3MaN3o7Zg fBJAKCMWUQlh4bfuKaPrUHheFZ0QvFMrFXajPNUyeRNPjO337K+l1pDPvJqAqG5yteJA pO+YduLDrbvvDLcPNBV/Xw2MCBLbervAvvsrU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IAETWjES8uXpHmh2p+OlheJi0sRrhAwHw9r6Px+awhqkdzAXXcMq7xM1z//XFwXjR9 DssEL5GD958U984VLRSta6ja3wrfEzJkfFQGmdJ8vl5nKYSDPukUJuszYVI0tHE23xxm r0/jsrOCdP00pukvVBHVk+I6E6Cpv0iJj5ccs=
I was having the same problem with the new cooking ISO, that tazx fails to copy the right files to the home directory, therefore slim refuses to log in except as root -- but I found the bug!
Line 20 in /usr/bin/tazx reads: USER=`cat /etc/passwd | grep 1000 | cut -f ":" -n 1`
The problem is that user tux is actually 1008 on my system, so USER=null which causes the configuration files to be copied to /home instead of /home/tux, and the script ends with a chown error. After changing 1000 to 1008 and running the script again, everything worked as it should, and I can now log in as a regular user.
I question if the script can handle multiple users, too.. Not only is tazx used in live mode or during an install, but it could also be run later when there may be more than one regular user. I don't see how it's capable of handling that, so anyone using adduser will inevitably run into the same problem. I'll leave it to the coders to fix this the right way, but I wonder if maybe slim should invoke tazx on more of a per user basis, if .xinitrc doesn't exist. This would allow for the creation of new users with individual configurations. However it happens, though, there's surely a better way to handle the USER variable.
I'm posting this on the mailing list, instead of in IRC, because I suspect this issue affects a number of people.