Description of problems: 1. User cannot login in with home directory although it exists. 2. Sub-logins (e.g gnome-terminal with "run as a login shell") fail for both root and the user Version-Release number of selected component (if applicable): Fedora-10 Beta How reproducible: Every time. Steps to Reproduce: 1. Install Fedora 10 Beta 2. Upgrade packages 3. login as a user or as root Actual results: 1. No directory /home/vladimir! Logging in with home = "/" 2. Session setup problem, abort. Expected results: No error messages Additional info: The initial install of F10-Beta seemed to work, at least for root. I don't recall that I tried as a user. /home/vladimir is a bind mount. /root, of course, is not. No gnome-terminals can be run by either root or by the user. They end up blank with a dialog to the effect that there was a problem. The session setup problem message comes from logging in a user then running login again. After the user is logged in (but without a home directory), "cd" works as expected and $HOME is correctly set to "/home/vladimir".
I re-installed F9 and did a massive update from {updates-newkey, updates), and I now get the no-home-directory message. I have tried .27, .26 and .25 kernels, and they all behaved the same. (.27 only on F10-Beta.) But ... with F9, even though I get the no-home-directory message, everything seems to work fine. My .profile and .bashrc are executed; gnome-terminals function properly; env appears to be OK. So, I don't know where that leaves us. I noticed that the component has been set to "lock-keys-applet". I don't know what that is, and I don't think I'm using. Regardless, it unlikely to be the lock-keys-applet because I have problems when GNOME isn't even running.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Please, can we close this bug or the problem still persist?
(In reply to comment #3) > Please, can we close this bug or the problem still persist? Someone has already closed this bug and marked it as "not a bug". Since there has been no activity in 8 months, I'm not going to spoil this perfect record by changing anything.