Description of problem: If you enter a username and password into sddn Login screen, and the login fails, both the username and the password are left entered. While this makes sense for the username, it makes no sense for the password, since there is no way to fix the password except reentry. Ie, You have to backspace or delete every character in the hidden password to retry the password. This is new behaviour and likely unwanted by almost everyone. Version-Release number of selected component (if applicable): sddm 0.14.8-12.mga6 How reproducible: Always.
CC: (none) => marja11Assignee: bugsquad => kde
I can confirm and also the error message is hardly visible, so that can make users believe that their password was not taken into account.
Source RPM: sddm? => sddm
Priority: Normal => HighTarget Milestone: --- => Mageia 6Severity: minor => normal
I made a fresh install with sta2 and updated the system with cauldron. I can confirm this bug.
CC: (none) => ed1
Uploaded sddm-0.17.0-3 for cauldron with the bundled theme modified to blank an incorrect password. Also bumped up the font size for the incorrect password message that is displayed. If neoclust approves, I will submit the same changes for mga6.
CC: (none) => mrambo
Updated package uploaded for Mageia 6. Advisory: ======================== Updated sddm package fixes bugs: This update fixes usability issues described in mga#19988. * an incorrect password is not blanked causing the user to have to backspace * the password error message is in a small font and difficult to see Updated packages in core/updates_testing: ======================== sddm-0.14.0-13.1.mga6 from sddm-0.14.0-13.1.mga6.src.rpm Note that these fixes apply to the default mga-coffee theme bundled with sddm. If sddm has been changed to use another theme the changes (and even the original problem) may not apply.
Version: Cauldron => 6Assignee: kde => qa-bugs
Mageia 6 :: x86_64 Well this should have been an easy one but it has caused a lot of grief. I confirmed the problem before the update and checked that the Mageia coffee theme was being used. After the update I was unable to logout so tried an emergency reboot. After 10 minutes it was obviously not going to work. Tried to see what was going on using a virtual console. No luck. Rebooted again and from level 3 downgraded sddm. Rebooted and still nothing. No idea what to do at that point so reinstalled from scratch. Two hours later installed and configured virtualbox and tried the update in a 64-bit guest. It worked perfectly. Fine. Tried the update on the host again and, failure. Would not boot to the desktop. So, going to be out of circulation for a while to rebuild the system. That was my production machine until very recently and is still important. The good news is that the update appears to work in principle - there is just something odd about running it on real hardware. The only other thing I can do is try it on a spare partition on a little used laptop. Later.
CC: (none) => tarazed25
I am not sure what you mean by "I was unable to logout"? What were the symptoms? Are you booting quiet or with splashscreen? (Ie remove the quiet from the kernel command line in grub) On reboot, where do things hang? No idea what "No luck" means. Certainly if the bug fix does stuff like this then it should not be out there. The question is whether it is some peculiarity of your system or is generic.
By 'no luck' I mean I could not figure out any way to investigate it or get it to work. Well I tried this on a laptop. Chose a partition with Xfce on it. Installed sddm and restarted dm from mcc. That worked and I checked the bad password issue and then logged in with the correct password. Ran the update and restarted the dm. That blanked the screen and as far as I can remember hung for a while before coming up with the "Good luck" message. That means it cannot run X. The message instructs the user to login as root at the virtual console and run drakx11 to configure a video driver. This is a situation very familiar to people in QA. Tried reinstalling the nvidia driver and rebooting. Back at the "Good luck" screen eventually. Tried the vesa driver and went round the loop again. Then tried nouveau and ended up in the same place. There is just no way to launch Xorg which means that that partition is now trashed, inaccessible except in run level 3. The boot journal is meaningless to me. There is a group of messages about raid6 (?) - there is no raid on that laptop. Furter on there are 5 identical messages about [Firmware bug] and trying a particular kernel parameter if the video driver does not work. Anyway the journal has been saved - shall dump it onto a USB drive in the morning. Far too tired just now.
Re comment 6. I just use the defaults for booting; the Plymouth screen comes up and bubbles away for a while and sometimes switches to text mode and back to graphics. When things hang I use Esc to see what is going on but it does not always respond. The major point is that sddm somehow breaks X. These problems have occurred on two completely different machines, a laptop and a workstation.
Created attachment 9936 [details] boot journal after failure to launch X server post update
OK. Had another go at running this update, choosing another partition on the laptop used previously. 1) Installed sddm 2) Selected sddm in mcc -> boot -> change display manager 3) Elected to restart at this point 4) Login screen appeared - logged in OK 5) Updated sddm 6) systemctl restart dm 7) Screen blanked as expected but then dropped down to console mode. "Sorry, there has been a problem blah blah blah Login as root and run drakx11 to install the graphics driver. systemctl default to connect to the X server Good luck!" 8) Installed the nvidia driver again. Past experience showed that systemctl default goes nowhere so took the advice to reboot and ended up at the "Good luck!" screen again. 9) Downgraded sddm 10)Reinstalled the nvidia driver 11)# lsmod | grep nvidia showed that the nvidia module was loaded 12)# systemctl default Led back to the "Good luck" message screen. So it is a damned if you do and damned if you don't scenario.
Whiteboard: (none) => feedback
I must admit I find this bizarre. As I said the only changes from sddm-0.14.0-13.mga6.src.rpm to sddm-0.14.0-13.1.mga6.src.rpm are those two lines in mga-coffee/Main.qml where line 48 was added password.text = "" and line 206 (in 13.1) was changed to font.pixelSize: 12 from font.pixelSize: 10 It is really hard to figure out how either could result in a non-bootable system. But you could change them one at a time, recompile sddm and see which of them causes the trouble. Of course the fact that it apparently causes you to have to reinstall each time is a severe damper on doing any testing. The one which I would suspect as causing the reboot is the second, since it actually changes something on the screen (the size). But how that could effectively switchoff you video card is completely obscure.
Bizarre it certainly is, especially when it works perfectly in vbox. I shall try to get hold of the source code and try again on another spare partition some time - we are overloaded right now in QA. The strangest thing though is that downgrading leads to the same problem with X. The fact that the problem manifests itself on different machines effectively rules out accidental memory or disk errors. I shall get back to this when I can.
One possibility is that the mga-coffee files are not getting changed back when you reinstall 13. The files are in /usr/share/sddm/themes/mga-coffee. Look in the Main.qml file and see if those two lines have been changed. Ie, password = "" and font.pixelSize=12 Or try changing them by hand.
That is a very good idea. I had found that file and was trying to figure out what could possibly go wrong. The bad partitions have all been wiped so I shall try the experiment again, later, and examine the file in runlevel 3. Thanks.
I have this update running on three different mga6 machines (and also two cauldron machines which have the same changes) without any problem. I started to downgrade and then re-upgrade my machine at work using the mirrors instead of using my locally produced package to see what was happening but noticed that the sddm package on the mirrors is wanting to pull in a lot of other packages - most of them qt5 related. When I do this locally sddm is just one package - sddm. I wonder if this is happening because neoclust is in the middle of doing that massive update of qt5 and the sddm package is being built against the new stuff that is not yet complete and it is this that is causing the problem. I'll try to ask neoclust about this but I'd recommend NOT testing this update any further until we know why sddm is pulling in a bunch of other packages.
CC: (none) => mageia
can we postpon this right after the qt5 update ? :)
As you can see ^^^ the in progress qt5 update is why this happened. Bad timing. Sorry it borked your system though Len.
Whiteboard: feedback => (none)
re comment 13 This looks like the qt5 update is the culprit. Certainly one of the qt5 packages was pulled in on the sddm update. I experimented with the Main.qml file and confirmed that changes to the file did not break anything. (As an aside - fontsize 14 worked better on my system and the error message was more readable with 'orange' rather than 'red'. Logging i and out - no problems. Restarting the dm from mcc or systemctl was OK. Updated sddm and checked the qml file to ensure that the changes were in place and changed them to suit my system. The first sign of trouble was failure to logout using the session item in the menu. Rebooted instead and ended up with the no X driver problem. So, yes, we should leave this until qt5 settles down.
@Mike re comment 17. de nada - we live in a hazardous environment.
I had problems with qt because some files were stupidly placed and sddm could not find them. They might have reverted again. Mind you that only killed sddm, not the whole graphics card. But yes, that would explain why updating sddm could not be reverted since the reversion would not backpedal the qt update. bug 20010.
Re comment 18, I agree that orange is much more readable. Red is too near the same brightness as the background. I shoved the font up to 20 and I at least like that better. The Login Failed is completely clear at that scale. (It is just slightly larger than the original white text there.) For the present until the qt5 issue settles down, perrhaps one could have a "fix" which just edits the installed Main.qml and changes those two lines, instead of installing a whole new sddm (which will fall into the qt5 trap).
I was about to give this one a try, but after reading all this I'm glad I didn't. Obviously, it pays to read the bug reports before testing! But now I'm wondering, if this is being put on hold until after the QT5 etc. updates, shouldn't it be removed from the repositories and the madb list until then? Even if sddm would be considered a part of the QT5 updates, I would think the separate bug should be removed from the list. For now. We wouldn't want others falling into the same trap Len did, simply because they didn't read the whole report.
CC: (none) => andrewsfarm
Comments 21 and 22 point the way to go - put the current update on hold and replace it with the fix, if that can be implemented as an update.
tagging as feedback until it gets an ok to rebuild again for the big qt/plasma update
Keywords: (none) => feedbackCC: (none) => tmb
Come to think of it... If you want to get it to work now, a proper set of buildrequires/conflicts should force the use of stuff not in testing
Keywords: feedback => (none)CC: (none) => qa-bugsAssignee: qa-bugs => mrambo
Depends on: (none) => 22657
FWIW, I checked about a week ago after updating to Plasma 5.12.2 etc. without applying this patch, and the problem was still there. Installing the patch made it go away.
It is the sddm package that contains the file that needs to be changed. What version of sddm do you have? rmp -q sddm
Ah. OK. I had remembered seeing a package that involved "sddm" among the 500+ packages that comprise a complete Plasma 5.12.2 update, but now that I look more closely sddm itself was not among them. The package I saw was sddm-kcm 5.12.2, a system settings configuration module. Still, it should be nice to know that the patch does work with the new Plasma update.
Rebuilt against the now completed qt5 in the Mageia 6 Grand Update and reassigning to QA. Presumably will no longer pull in libraries which trash the test systems (see comments 16 and 17). I did not go back and further modify font size or color as mentioned in comment 18. I thought that was more appropriate for the package maintainer to do. This update is about fixing the functional bug that was submitted and neoclust had approved doing this fix. Updated Advisory: ======================== Updated sddm package fixes bugs: This update fixes usability issues described in mga#19988. * an incorrect password is not blanked causing the user to have to backspace * the password error message is in a small font and difficult to see Updated packages in core/updates_testing: ======================== sddm-0.14.0-13.2.mga6 from sddm-0.14.0-13.2.mga6.src.rpm Note that these fixes apply to the default mga-coffee theme bundled with sddm. If sddm has been changed to use another theme the changes (and even the original problem) may not apply.
Assignee: mrambo => qa-bugs
Mageia 6, x86_64 sddm already in use, with mga-coffee theme. Checked /etc/sddm.conf. Oddly enough, the 13.1 version did not display the original problem. I forgot to check Main.qml but I suspect that it contained the correct code already. No change after the update; the password field was cleared after input of a bad password. The error message was perfectly legible also.
Whiteboard: (none) => MGA6-64-OK
Quickly re-testing M6/64 All Qt5 etc stack updates applied. BEFORE update: sddm-0.14.0-13.mga6 Comment 29 indeed applies. AFTER update: sddm-0.14.0-13.2.mga6 After failed login, the password field is cleared. If the font size for the red error msg is larger, it is marginal; never mind. Agree with Len update OK. Advisory from c29.
Keywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2018-0087.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED