F22 unusable - system freezes on login

[Chris Murphy]

On Thu, Jul 2, 2015 at 1:05 PM, Matthew Woehlke
<mwoehlke.floss at gmail.com> wrote:
> On 2015-07-02 13:56, Chris Murphy wrote:
>> On Thu, Jul 2, 2015 at 11:41 AM, Matthew Woehlke wrote:
>>> I recently installed F22 (KDE spin) from scratch on a new Dell M6800.
>>> The Live CD seems to run okay, but when I try to boot the installed OS,
>>> it freezes when I try to log in. The machine is effectively unusable as
>>> a result.
>>
>> Is it actual frozen?
>
> The login *process chain* is frozen. On a "good day" (although I don't
> think this has been the case since the originally-installed kernel) I
> can switch to a different TTY and futilely try again.
>
>> Or you just can't see anything on the display?
>
> The display is unchanged; I still see the login dialog / prompt /
> whatever was on screen previously. (Although with updated kernels, TTY
> switching results in an unrecoverable black screen.)
>
>> Can you ssh into it?
>
> Ah... no?
>
>>> This affects login regardless of the method: graphical, tty, *SSH* [...]
> (emphasis added)
>
> That is, ssh connects, but the login never completes and I never get to
> a shell. I get "Last login: [...]", and then nothing; it's stuck at that
> point. (And if I kill ssh and try again, I can still connect, so indeed,
> the kernel is still alive.)
>
> (In my various attempts to make things better in emergency mode - the
> only way I've been able to get a usable shell - I was able to enable
> sshd and coax the network into coming up on boot.)
>
>> Try booting with boot parameter nomodeset. Does that change anything?
>
> Hmm... Yes. Seems to work okay with nomodeset. But why does that break
> *ssh*? (And where - that is, against what - do I file a bug report?)

If nomodeset solves the problem, then the problem is graphics related.
You can use:

journalctl -b-1

to get information about he previous boot and

journalctl -b-2

to get information from the boot before that, etc. Current boot is -b
/ -b-0 which isn't as helpful because it will contain the successful
nomodeset boot. But the previous boot will get written to the journal
as long as switchroot happened.

Another possibility is that this is just a problem with gdm on Wayland
with your hardware and not a more general problem. So to disable gdm
on Wayland, to revert to gdm on X, you need to edit:

/etc/gdm/custom.conf

And uncomment the WaylandEnable=false line. Then reboot (without
nomodeset). If that also solves the problem, then it's a gdm on
Wayland problem.

Once you've figured out in what case the failures do and don't happen,
you'll know which component to file the bug against, and what to
include in the bug report.


Chris Murphy



-- 
Chris Murphy