Description of problem: hardware; older i7 920, 6Gb, dual SSD in RAID0 Nvidia 1650 graphics card. Uneventful install, Selected using the proprietary nvidia driver when asked during the install. Everything worked normally on first boot. in particular, xfce worked normally. Confirmed with one further reboot. Problem: during that second boot I installed a few selected packages (task-printing etc) then did full package update. On reboot, everything progresses normally to the login prompt and text under this indicates login succeeded, but rather than progressing to desktop, goes immediately baqck to login prompt. With one exception, every possible desktop fails in identical way. The one exception is Gnome. Martin Whitaker kindly pointed out in qa discussion that Gnome uses Wayland; everything else is X. Something in the 700-odd update packages is killing X. I'll do some digging around in the system and find some data to go with this bug report. How reproducible: I've just done a complete re-install, formatting the install partition. Again had normal working system with expected graphics on first boot, and replicated the 'killed all X' after full package updates.
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, tmbAssignee: bugsquad => pkg-bugsPriority: 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
CC: lewyssmith => (none)
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) => FIXEDStatus: 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