Bug 29599

I note in passing that there is no Xauthority file anywhere on the system.
In particular, it is not in /run/user/1000/gdm.  There are several other files in that location, some related to Wayland, all correctly owned by tony

.. so it doesn't seem to be the problem bug-reported around M5, where the Xauthority files came to be owned by root and fixing their ownership fixed te problem.

Created attachment 12968 [details]
Xorg.0.log

the first Xorg log file on this new system, which worked normally before updates

Created attachment 12969 [details]
the later Xorg log file

Created attachment 12970 [details]
exported journalctl file

exported journalctl file

Have you tried switching from gdm to sddm or xdm?

CC: (none) => davidwhodgins

Thank you Tony for all the evidence.
This problem - logging in takes you back to the login screen - rings a bell, we had another bug on that precisely. To find...

To save others the pain, the two Xorg log files are identical up to the last screen - lines, really. They start to differ on the 'Option "fd"' lines, but are still essentially the same except for just this:
[  2008.206] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[  2008.206] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
between the last two lines for the *updated system* only.
There might be a clue here, but they are only warnings.

The attachment 'exported journalctl file' is unfamiliar. Since the fault happens immediately after booting (first login attempt), dmesg O/P should suffice.

CC: (none) => lewyssmith

Created attachment 12972 [details]
coloured journalctl output with gdm

In an attempt to make journalctl more readable (sorry for prior) I've found and used:

script -q -c "journalctl -b -1 --no-pager" colored.txt > /dev/null

If you then read colored.txt with 'more' the output will be coloured, highlighting errors

Generated colored.txt by using GDM, choosing something other than gnome so login would fail, then running the above script.

In addition to GDM info as per the colored.txt file attached above, 
I also tried:

SDDM
failed to reach login prompt, nothing graphical at all
Lots of error messages of form
Failed to read display number from pipe
Attempt2 starting the Display server on vt 1 failed
Exec binary "/usr/libexec/xapps/sn-watcher/xapp-sn-watcher" does not exist.  No such file or directory
Not generating service for XDG autostart app-xapp\x2dsn\x2dwatcher-autostart-service
error parsing Exec= line  No such file or directory

Xdm:
many messages of form
xdm.service: Failed with result "protocol"
Failed to start X11 Display Manager


Hmmm, all this just from updating packages on a system which worked entirely normally just after first installation.

Just wondering here. What's the output of
$ tree -ifaug .dbus

Also, try creating a new user and see if it can login ok.

(In reply to Tony Blackwell from comment #7)
> Created attachment 12972 [details]
> coloured journalctl output with gdm
> 
> In an attempt to make journalctl more readable (sorry for prior) I've found
> and used:
> 
> script -q -c "journalctl -b -1 --no-pager" colored.txt > /dev/null

In the future, add the option "--no-h" (short for --no-hostname) to the
journalctl command to make the lines shorter.

tree -ifaug .dbus
.dbus [error opening dir]
0 directories, 0 files

New user fares no better: gets in with gnome/wayland but nothing else.

#10 noted with thanks.
Tony

Thanks for trying other display managers, comment 8. Disappointing that they all failed in their own way. The journal 'colored.txt' should tell someone what happens. Mystified by (but it is true!):
> read colored.txt with 'more' the output will be coloured, highlighting errors
Do not know where to assign this. It has to be generally, CC'ing Thomas & Jani who may have ideas.

CC: (none) => jani.valimaa, tmb
Assignee: bugsquad => pkg-bugs
Priority: Normal => High

Afterthought: if you have Plasma also, that too can with additions run under Wayland (separate session menu entry).

your system is not updated according to logs that references nvidia-current 460.39 driver....

In Nonfree Updates we have 470.74

Hmmm, not sure what is going on here I've previously demonstrated the bug on multiple occasions on this one desktop box following the sequence of 
1.initial install and reboot (installed with 'all languages")
2. configure sources, then install virtualbox, wine, webmin, thunderbird, task-printing-hp, task-scanning and the tainted versions of task-codec.
3. update system
following which only gnome (Wayland) will launch.

Trying to bisect this I've done a myriad fresh installations on same box with partition format between, with the results:

a. install followed by urpmi --auto-update installs 542 packages and system reboots normally without problems.  Using mcc finds no more packages to update.

b. Another complete re-installation, no packages added at reboot, just straight into update system via mcc, and 547 packages are installed with system rebooting normally.  Then added the short list of packages mentioned above (wondered if vbox might be a culprit) but system still reboots normally with any desktop available.

I can't identify what subtle, perhaps sequence-related, issue has caused this problem, but for the moment probably better to close it pending any more insights.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Thank you for the tests and closure.

It may be (is hopefully) impossible to replicate the failure as updates have moved on.

CC: (none) => fri