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):
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.
I made a fresh install with sta2 and updated the system with cauldron. I can confirm this bug.
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.
Updated package uploaded for Mageia 6.
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:
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.
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.
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
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.
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
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
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.
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.
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.
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.
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
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
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
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.