May 07, '04 08:45:00AM • Contributed by: krishna
If you log in with the uncustomized account, and everything works, then you know it's not a system problem. You can then (a) ssh to the same system (via ssh localhost) but log in as yourself, and see if you can connect; if you can, this proves that the basic unix functionality of your account is OK; (b) if you can't ssh over, at least you can sudo over to your account, and maybe move some of your customization files out of the way (say $HOME -> Library -> Preferences -> loginwindow.plist or your dotfiles, if you've customized them); and (c) the fact that you can log in to an uncustomized account means that most likely the system upgrade went OK, and one of your customizations (startup apps, preference files, etc) is potentially a culprit. Even if you don't know what you're looking for, you can at least get a knowledgeable friend in the same room with the system to check things out.
If you do see the same problems with the uncustomized account as with your own account, then you know that the problem's with the system upgrade, and maybe you should restore your backup, try upgrading in a different way, verify/repair disk/permissions, or perhaps a wipe and reinstall (and run hardware diagnostics while you're at it).
This bit me hard during the Panther upgrade (which is working great for me now, though). Since the bulk of the customizations to a system will be in an individual user's home directory (per the UNIX model), an uncustomized account will help identify problems you discover during an upgrade a lot faster, hopefully in a matter of hours rather than days. You can always remove the account after the upgrade if you're worried about it being a security issue.
I recommend this for anyone upgrading Mac OS X, from a 10.n to a 10.n+1 release (or even 10.n.m to 10.n.m+1 release, if you're paranoid enough).