F17 installed alongside F16: now can't log in to F16

[JonAllan]

I have long been using F16 on my machine (Asus K52F). I recently installed F17 on another partition (overwrote Windows at last!). F17 works fine. But now I can't log in with F16 (which for a short transition period I need to do). All well to the login screen; then when I enter the correct password, the screen goes black for a few seconds, then returns to the login screen again. (If I enter an incorrect password it tells me that the password is incorrect; so it is not that the password has somehow changed.) I tried Ctrl-Alt-F2, the terminal with 'log in:' - it gives 'password incorrect' if I use a wrong word, but simply returns to 'log in:' if I do give the right password. Thanks for any help to get F16 up again for a while, even if nec. as root.

[tashirosgt]

Can you examine the files in the FC 16 installation while you are booted in FC 17? If so, I suggest looking in the log files of FC 16 to see if they show any logins followed by crashes or other problems. There are all sorts of logs in the /var/log directory. It is helpful if you reproduce this problem and note the exact time, down to the nearest second since some logs (like /var/log/messages) have timestamps. Core dumps are directories in /var/spool/abrt with names that give a date and time.

The file /boot/grub2/grub.cfg shows the details of what happens when you select a given booting option. Do they look right?

What does the command df show when run it from FC 17? Did the partitioning come out like you expected?

[JonAllan]

Thanks, Tashirosgt, for answering. Yes, I can access Fed 16 from Fed 17. Have rooted around in /var/log. I don't know enough to make much of it, but have included extracts.
'messages' file- times are:
-- boot at 9:57:26;
-- click on log-in message box to bring up my user name ('jon') at 10:07:10;
-- key Enter after entering password: 10:09:06.

Boot log seems OK, as does the output from 'df' (from Fed 17 terminal).

[tashirosgt]

Let me make sure I undestand how you are picking which Fedora to use. As I read the grub.cfg file, it is only for FC 16. So evidently, you don't pick which Fedora to use from a grub menu. Do you go into BIOS and set a different HD boot priority? Or is this handled by some OS switching type of program?

Post the output of

fdisk -l

"-l" uses the letter "l", not the number one.

(This is what I should have recommended in the first place for getting a picture of how the hard drive partitions are detected).

An example of a successful login session on my FC 16 machine:

Jun  2 13:29:13 comp12 systemd-logind[989]: New session 2 of user cosmo.
Jun  2 13:29:13 comp12 systemd-logind[989]: Linked /tmp/.X11-unix/X0 to /run/user/cosmo/X11-display.
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GdmSignalHandler: handling signal 15
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GdmSignalHandler: Found 1 callbacks
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GdmSignalHandler: running 15 handler: 0x41bf30
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): Got callback for signal 15
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: Logout called
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmShell: Not connected to the shell
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: requesting logout
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: ending phase RUNNING#012
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: starting phase QUERY_END_SESSION#012
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: Client /org/gnome/SessionManager/Client1
Jun  2 13:29:13 comp12 gnome-session[1192]: DEBUG(+): GsmManager: Client /org/gn:

I'll have to research what the differences between mine and yours indicate.

The log /var/log/secure shows successful and unsuccessful authentications of logins. See if your login was authenticated. If it was, then we can assume the password file isn't the problem. (You can deliberately do a login with a bad password to see what a failure report looks like.)

[ergosum]

I had a similar problem after an installation of F17 into a disk where there was a previous F16 installed.

I solved putting the SELinux in permissive state in F16. After login with F17 I've mounted the F16 filesystem, and I've changed the file /etc/sysconfig/selinux by putting:

SELINUX=permissive

Then I can do login into F16 and setroubleshoot gives me some warnings that help me to find the problem (gdm was not able to access some files). So I solved with these commands:

# restorecon -Rv /etc /tmp
# rm -rf /tmp/at-spi2

I suppose that a recent update of F17 has altered the F16 context, because the F16 filesystem was mounted during updates. From the F17 log:

# grep selinux /var/log/yum.log
Jun 02 15:46:41 Updated: selinux-policy-3.10.0-125.fc17.noarch
Jun 02 15:51:47 Updated: selinux-policy-targeted-3.10.0-125.fc17.noarch
Jun 02 15:51:50 Updated: selinux-policy-devel-3.10.0-125.fc17.noarch

Hope this helps.

[JonAllan]

Thanks guys for ploughing through my log files. Greatly appreciate your time and effort.
Through F17 I made the F16 change 'SELINUX=permissive' as suggested (Ergosum), which allowed the boot into F16. Then the sealert browser provided me with a huge list of alerts (before I did anything at all) - 50 to 80 on different boots - objecting to attempts to read even by bash and sealert itself; and to all sorts of attempts by Xfce 4.8 (my desktop) to read files. The particular fix with 'restorecon' did nothing for me. I will probably leave it there, as I am now just doing last minute things with F16 (e.g. snapshots) and then abandoning it (F17 with Xfce is great!).

[ergosum]

If you want to avoid alerts, try:

SELINUX=disabled

Reboot, then:

SELINUX=permissive

Reboot again, this will cause a total relabel of the filesystem.

[JonAllan]

Thanks, ergosum, problem fully solved. (Warning to anyone else doing the same: the total relabelling of the system takes a long time - have a meal break while waiting.)