Description of problem: Sddm greeter was working fine, displaying hostname etc. in dialoguefield, but after today's update of glibc etc. an empty field occurs. I already checked what fonts are used for the dialogue usually (dejavu sans) and these fonts still are installed. On a 64-bit system this issue does not occur.
Created attachment 14332 [details] Screenshot regarding issue "Sddm-greeter: after today's update shows no hostname, no labeling no nothing"
Can't reproduce in my i586 system but I did have other sddm theme and apply mageia theme, close the session and check What is the output of rpm -qa|grep sddm Also check ~/.local/share/sddm/xorg-session.log
I see it (maybe it is this, but looks different) on one of my systems: On my Dell Precision M6300 there were occasional artifacts before, but after latest updates there are just different size white rectangles instead of characters - at first login; after suspend resume it is OK. Weird. Even more weird is that everything in sddm is perfectly OK on an external screen connected to VGA at the same time they are bad on the laptop screen. mga9-64, all updates + kernel-desktop-6.6.14-2, nouveau
CC: (none) => fri
(In reply to Morgan Leijström from comment #3) > Even more weird is that everything in sddm is perfectly OK on an external > screen connected to VGA at the same time they are bad on the laptop screen. > My i586 system is a laptop with broken display, so is permanently connected to an external monitor, then if the issue exists in my system I don't see it
I believe it is some kind of initialisation problem. @Markus: On the affected system, if you log in to desktop and then § log out to SDDM again: problem visible? § suspend-resume: problem visible? I guess the problem do not show using another DM than SDDM? Have you tried reverting updates to see what trigs this?
You could try sddm-0.20.0-5.mga9.x86_64.rpm from core updates_testing. I am using it on another system already. Should try on my affected system.
(In reply to Morgan Leijström from comment #6) > You could try sddm-0.20.0-5.mga9.x86_64.rpm from core updates_testing. > I am using it on another system already. > Should try on my affected system. sddm-0.20.0-5.mga9.i586.rpm , because the reporter say the affected system is i586
Seems already had that new sddm on this problematic system too. Changed theme to breeze, same problem. It does not help to suspend-resume from sddm at first login since boot, but if i have entered desktop (Plasma) then sddm shows OK at logout or suspend-resume.
I also tried installing theme sddm-theme-coffee-ng-2.0-1.mga9.noarch and selected it "Mageia 2.0" in Plasma settigs: Same issue. Tried other Display managers: XDM, LifhtDM, LXDM: all works Sidenote: I now understand that on resume the login display is always a Plasma part. For this system i have seen issues for long, it is just that before, the text characters was substituted by aproximatelu character wide blocks, but recently by narrow "|" looking "characters"
CC KDE team
Hardware: i586 => AllCC: (none) => kde, ubuntu
(In reply to Morgan Leijström from comment #9) > LifhtDM Meant LightDM
Status: NEW => NEEDINFO
sddm requires pam did you test with pam from https://bugs.mageia.org/show_bug.cgi?id=32746 ?
Created attachment 14335 [details] SDDM after boot on Dell Precision M6300 Characters are replaced by small vertical bars. (But after login-logout they are OK until next boot)
...and yes that screen is dirty... (In reply to katnatek from comment #12) > sddm requires pam did you test with pam from > https://bugs.mageia.org/show_bug.cgi?id=32746 ? Yes, made no difference.
Created attachment 14336 [details] This time most characters are rextangles. This is with theme "Mageia 2.0" see Comment 9.
More to comment 8: That figure "8" top right is clock minute. When SDDM first came up it was shown as a filled rectangle block, but on the minute shift it became a correct 8. Before that, i was filli gin my password and it was correctly shown as dots, but when minute struck the dots became black field, shown in picture. Also the dropdown desktop selection also list black blocks. I let it be for a while and it seem like that for every minute, characters/blocks vanish, nearing the completely text-less dialogue in comment 1. Two pictures showing that follows.
Summary: Sddm-greeter: after today's update shows no hostname, no labeling no nothing => SDDM first login after boot shows no text, or characters as blocks.
Created attachment 14337 [details] After couple minutes, some text blocks have disappeared
Created attachment 14338 [details] After more minutes, almost all characters/blocks have disappeared
As i told I have seen this for long but did not mind open a bug as this is an old machine and I had not seen anyone else complain... Now after updates Markus begin to see this, comment 0 I wonder if this may be a question about execution order, that sddm need something to be executed before, but depending on system and software versions the parallell execution of many tasks change which task get really ready before sddm? As a test, is there a way to delay the launch of sddm a few seconds?
Keywords: (none) => FOR_ERRATA9
https://wiki.mageia.org/en/Mageia_9_Errata#Various
Keywords: FOR_ERRATA9 => IN_ERRATA9
(In reply to Markus Robert Keßler from comment #0) > Sddm greeter was working fine, displaying hostname etc. in dialoguefield, > but after today's update of glibc etc. an empty field occurs. > On a 64-bit system this issue does not occur. If you others agree that this occurs just on x32, accept my 'Hardware' change. If you have seen it on x64, please revert it to "All'. Assigning to Plasma people; the bug reporter is not alone.
Hardware: All => i586Assignee: bugsquad => kdeStatus: NEEDINFO => NEW
My system is x64. (BTW that setting have bad granularity - no idea if it happens on ARM...) Needinfo was because I hope reporter could get back with what package update made this problem visible on his system.
Hardware: i586 => All
My real 32-bit hardware won't run Plasma or sddm because of the antique AMD GPU, so I can't test there. I have a 32-bit Plasma install on 64-bit hardware, AMD Phenom II X4 910, AMD HD 8490 graphics. It uses the server kernel, if that makes a difference. I had not run it in a while, and had many updates, including the kernel, glibc, and systemd. On all updates, when asked I chose to use "rpmnew" as the main file on this install. I usually have auto-login enabled, but for purposes of this test, I disabled it (of course). I do not see the issue on this hardware. Has anyone tried this in VirtualBox?
CC: (none) => andrewsfarm
new mesa in testing: no change I see same problem using Xorg nouveau or Xorg modesetting. WORKAROUND for both: disabling hardware acceleration. (that checkbox in drakx11, after selecting driver) However of course graphics becomes painfully slow. (And on this machine especially with nouveau it is slow, plus resume after suspend fail. Modesetting is faster and resume works. Too old GPU for proprietary drivers.) Only when using SDDM with hardware acceleration and nouveau or modesetting, i see in journal: feb 09 20:21:02 M6300.tribun kernel: nouveau 0000:01:00.0: fifo: DMA_PUSHER - ch 3 [sddm-greeter[1840]] get 0000216008 put 0000216088 ib_get 00000007 ib_put 00000008 state 800088b4 (err: INVALID_CMD) push 00406040 Other users experiencing the problem, do you see this too? I am switching to LightDM for now.
CC: (none) => kernel
Now I saw it on my Thinkpad T510, Plasma, 64 bit, Intel $ inxi -G Graphics: Device-1: NVIDIA GT218M [NVS 3100M] driver: nouveau v: kernel Device-2: Lenovo Integrated Webcam [R5U877] type: USB driver: uvcvideo Display: wayland server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9 compositor: kwin_wayland driver: X: loaded: nouveau,v4l dri: nouveau gpu: nouveau resolution: 1920x1080~60Hz API: OpenGL v: 3.3 Mesa 23.3.5 renderer: NVA8 After installing a bunch of updates a couple days ago and yesterday rebooting with New KF5, and kernel-desktop-6.6.16-3 from testing, then i saw it. Now I updated to kernel-desktop-6.6.17-3, rebooted, and i did *not* see the problem. Same error message as when it borks on my other computer is seen when sddm show garbage: $ journalctl -b-1 | grep INVALID_CMD feb 20 13:15:57 localhost kernel: nouveau 0000:01:00.0: fifo: DMA_PUSHER - ch 6 [sddm-greeter[4791]] get 000021e004 put 000021e088 ib_get 00000007 ib_put 00000008 state 80000014 (err: INVALID_CMD) push 00400040 and another identical line the same second. This is not logged when it goes well. --- I guess there is some subtle timing that in rare occasions reveal that something that must be done in a specific order, is not done so. Maybe when we see it we should try to reboot with only one CPU core enabled, or somehow tell systemd or whatever to not do things in parallel, or... I dont know how to do anything of that. Some kernel boot parameter?
Or simply a diffuse problem with nouveau, which is in kernel IIUC. Closest i found in a web search: https://forum.manjaro.org/t/graphical-issues-with-kernel-6-6-10/156269 https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/477
Source RPM: sddm-0.19.0-16.mga9.src.rpm => kernel, sddm-0.19.0-16.mga9.src.rpm
Since kernel 6.6.18 and other updates, i have not seen that on my T510 anymore, but two variants: 1) all looks OK, but no dots show up whn i enter password 2) first login is OK, but after i had hibernate, then resume work, and then log out of plasma, sddm show strange blocks instead of characters. So also resume may fail (re)initialising somethig?
Now I see the problem in sddm every time first login on my Thinkpad T61 When testing sddm 0.21, mesa just releassed, and kernel-desktop 6.6.43
Interesting: I changed DM to LXDM, and rebooted. Result: LXDM login menu is full OK, as well at bottom screen "dropdown" selections etc, but rest of screen area is a mess mostly consisting of desktop backgroind and icons from previous login, apparently preserved in video memory during reboot, with many various rextangular areas of distortion and smaller white rectangles, all different sizes.
Solution: I changed graphics driver from default "GeForce 8100 to GeForce 415" ( = nouveau driver) to Xorg modesetting. GPU is Nvidia G86M [Quadro NVS 140M]. -and now both sddm and lxdm shows up fully correct! So this is yet another case where modesetting works better than nouveau. So at least in this case also another DM than sddm have (less) graphics issues at the same time as sddm, and both get ok when changing graphics driver. So maybe it is something like the DM assume graphics is initialised some way, or failk to do it itself, depending on driver? Maybe this is a kernel/driver issue, that gets revealed by sddm and lxdm. Or just a big gray area of what is responsible for initialisation etc of whatever... Maybe we should search upstream for bugs on nouveau.
Source RPM: kernel, sddm-0.19.0-16.mga9.src.rpm => kernel/driver, or sddm & lxdm, more?