Created attachment 8094 [details]
Xorg log file

Created attachment 8095 [details]
Xorg configuration file

I will provide a kernel log file by tomorrow 1/07/2016.

There's no error in your Xorg.0.log (you should probably have attached the .old one)
Though you probably want to update to x11-server-1.18.3-12.mga6

Keywords: (none) => NEEDINFO

Hi,

the Xorg.0.log.old is the same Xorgs.0.log. There is no error in it also.

When I type an accent character, the X server "explodes" immediately, perhaps leaving no trace.

Please find attached the dmesg in the case where the bug happens.

Regards,

Olivier le Roy

Created attachment 8100 [details]
dmesg

You did look at ~/.local/share/xorg/Xorg.0.log*, didn't you?

As for dmesg, "journalctl -b" output would be more interesting I thing.
eg if you'd a crash at 08:30, run the following command as root and attach the resulting file:
journalctl  -b --since "2016-07-01 08:30">/tmp/journal-18822.txt

Well, dmesg is enough this time:

 sddm[1707]: segfault at 0 ip 00007f9df9b59e73 sp 00007fff57afce30 error 4 in libQt5Core.so.5.6.0


sddm is crashing atlest twice, so no chance of it starting normally...

I changed the title, since this bug seems not related to the intel i915 driver, but a segfault in the Qt5Core library.

Where does the accented character -if related to the crash - come in? adduserdrake and userdrake give an error when trying to put an é, ü or ô in a login name.

So the accented character is in the password, correct?

CC: (none) => mageia

Hi,

there are no accent character in login, neither in password.

This is something I noticed, once, when I could have KDE or GNOME desktop running.

I was typing an email, and the X server suddenly exploded when typing "é".

I did the test multiple times with "é" and "â¬".

Presently, I can no longer have, since I tried the Nvidia proprietary driver, the KDE or GNOME environments, but I can reproduce in X session screen.

It is not even needed to enter the login or password, as soon as one of those accented character is typed, the X server vanishes, returning to a black console.

Regards,

Olivier le Roy

Thx for the explanation, I had started thinking sddm crashed much earlier, before having reached the DE.

Keywords: NEEDINFO => (none)

Hi,

thanks for taking care of this issue.

In My Humble Opinion, everyone who is running an up to date version of Mageia 6 Cauldron with Plasma or Gnome desktop environments and a french keyboard layout should reproduce this issue.

All that is needed, is press "é" or "â¬", or any other accent character, to make the X server crash.

This is really a blocking issue, since accented characters are extensively used in french text typing.

Regards,

Olivier le Roy

Hm, I'm French and using Mageia 6 with Plasma so I'm pretty sure I've inputted several accented characters over the last few days, but did not have a crash. Does it happen in any application, or is it limited to specific ones?

Hi,

as far as I remember, I had the bug typing in Firefox, but the most obvious way to reproduce is in the session logon screen, where the password is entered.

Regards,

Olivier le Roy

Hi Thierry,

sorry, I didn't look at ~/.local/share/xorg/Xorg.0.log*, but /etc/X11/Xorg.0.log*, I guess, which might be incorrect.

I will provide te requested logs by Monday morning 4/07 since I won't access my machine during the week end.

Anyway, do you know a way to trace the segfault in libQt5Core, like ltrace?

Have a good week end,

regards,

Olivier le Roy

I have eventually solved the issue.

The crash of my display manager was due to a segfault in pico-tts, which is a vocal synthesizer, when accent characters were typed:

[ 1167.300881] sd_pico[25833]: segfault at 7f0c01627010 ip 00007f0c049edd2c sp 00007ffcd8befa48 error 4 in libttspico.so.0.0.0[7f0c049e3000+4e000]

I uninstalled lib64ttspico0 (urpme lib64ttspico0) and I could resume typing accent characters with no crash anymore.

The fix, for me, is not to use pico-tts vox synthesizer which is installed by default.

Thanks for your help,

Regards,

Olivier le Roy

Resolution: (none) => FIXED
Status: NEW => RESOLVED
Source RPM: qtbase5 => lib64ttspico0

Well that's a fix "for you", but not for the distro. If pico-tts segfaults, it should be fixed.

Summary: Accent characters cause the Simple Desktop Display Manager (SDDM) to crash on xsession screen => Accent characters cause the svox-pico to segfault, triggering an xorg crash
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
Source RPM: lib64ttspico0 => svox-pico-20120212-1.mga6

I completely agree, uninstalling pico-tts is a workaround that allows to work with graphical environments, which was not possible before (and as such, it is a major bug), but it doesn't fix the actual issue in svox-pico.

@ Olivier,
can you please give steps to reproduce the problem.
I can't yet.
Papoteur

CC: (none) => yves.brungard_mageia

Hi Papoteur,

I made a fresh install of Mageia 6 Cauldron, with "Plasma destkop" default installation.

All my partitions were formated.

svox-pico was present.

To reproduce, I just have to wait that the X server is started, then I type "é" or "â¬" (anytime, anywhere, in the login screen or in plasma).

The issue is really obvious and makes my setup unworkable.

Later, I tried to install Gnome desktop, the result was the same.

There is always a crash of the X server when typing accent characters.

Maybe on your setup, the xdriver is not the same, maybbe it is more robust, but in the dmesg, you should see something like: "sd_pico[25833]: segfault at 7f0c01627010 ip 00007f0c049edd2c sp 00007ffcd8befa48 error 4 in libttspico.so.0.0.0[7f0c049e3000+4e000]".

Regards,

Olivier le Roy

David, you added this package recently.
Can you fix it or remove the package by obsoleting it through task-obsolete?
It looks like you've cherry-picked bits of some fixes (eg: 10% of commit d12fa9eb)

Remove??

$ urpmq --whatrequires lib64ttspico0
abuledu-microtexte
leterrier-aller
leterrier-calculment
leterrier-memorise
leterrier-mulot
leterrier-racont
lib64ttspico-devel
lib64ttspico0
speech-dispatcher
svox-pico
$

And I don't know how to fix this issue!

I can't repoduce this issue on my Cauldron.

@ Olivier,

Could you please test the latest lib64ttspico0 update on Core/Updates_testing repo to see if this issue is solved or not?

Thanks in advance!

svox-pico-20160125-1.mga6.x86_64.rpm
lib64ttspico0-20160125-1.mga6.x86_64.rpm
lib64ttspico-devel-20160125-1.mga6.x86_64.rpm

svox-pico-20160125-1.mga6.i586.rpm
libttspico0-20160125-1.mga6.i586.rpm
libttspico-devel-20160125-1.mga6.i586.rpm

Hi David,

sorry, I did the requested test, and lib64ttspico0 is not at fault.
It was a coincidence I had this segfault while the x server was crashing.

Now I would like to give my today's findings.

With kernel 4.7.0-desktop-0.rc6.3.mga6 I simply can't boot (boot process hangs before asking passphrase for encrypted partitions).

With kernel 4.7.0-desktop-0.rc6.2.mga6 the "accents" bug appears 3/3 with 1 segfault in libQt5Core.so.5.6.0.

With kernel 4.7.0-desktop-0.rc6.1.mga6 the "accents" bug appears 1/11 (the 1 occurence may be a faulty manipulation), with no segfault.

With kernel 4.6.3-desktop-1.mga6 the "accents" bug appears 1/1 with 1 segfault in libQt5Core.so.5.6.0.

With kernel 4.6.2-desktop-3.mga6 the "accents" bug appears 1/1 with 2 segfaults in libQt5Core.so.5.6.0.

With kernel 4.6.2-desktop-2.mga6 the "accents" bug appears 1/1 with 2 segfaults in libQt5Core.so.5.6.0.

With kernel 4.6.2-desktop-1.mga6 the "accents" bug appears 1/1 with 1 segfault "error 15"

To sum-up, except the 1 occurence I had, which may be due to a faulty manipulation, I don't reproduce the issue with kernel 4.7.0-desktop-0.rc6.1.mga6, but I reproduce it systematically with the 5 other kernels above.

Sorry again for the misleading in tts-pico.

Regards,

Olivier le Roy

Source RPM: svox-pico-20120212-1.mga6 => kernel 4.7.0-desktop-0.rc6.2.mga6

Hm, is your system fully updated ?

I see references to libQt5Core.so.5.6.0, but cauldron only have: libQt5Core.so.5.6.1

And there is a new kernel/mesa/libdrm/x11* packages ...

Hi Thomas,

the bug is still there with:
libQt5Core.so.5.6.1
kernel 4.7.0-desktop-0.rc7.1.mga6

Moreover, after I upgraded (180 packages) 4.7.0-desktop-0.rc6.1.mga6 is no longer a safe solution.

It means I have the bug on all aformentioned kernels.

Hopefully, I am typing in english, which doesn t trigger the bug.

I would be interested to know if anyone reproduces the issue.

Regards,

Olivier le Roy

I have a possibly related/identical issue with xorg exiting when I type the £ character. (Shift+3 on UK Layout keyboard).

In my case there is nothing in the logs to indicate it was a segfault, in fact it appears to be an orderly shutdown of xorg.

It repeats:
UnloadModule: "libinput"

a few times within a few milliseconds then there are some Console input/ouput errors followed by
"server terminated successfully"

This happens with both IceWM and Plasma.

CC: (none) => smorgan

Hi Stuart,

I see the segfault in dmseg.

E.g.: "dmesg | grep -C 2 segfault"

I get the same logs as yours in xorg.0.log (UnloadModule: "libinput" ... "server terminated successfully").

If I do a "ltrace -p (sddm process)", nothing relevant appears, it seems.

I hope this helps.

Regards,

Olivier le Roy

I see sddm segfaults but they do not coincide with the exit from xorg -

It might just be that xorg server exits after a couple seconds because there's no more X11 client...

The sddm segfaults occur during or just after booting on my system. I just triggered the issue again after the machine had been up for 4 hours, the only sddm segfaults were between the 60-80 secs mark.

These two segfaults do coincide with the issue though, first in kactivitymanager (faults in libQt5Sql) and second in QDBusConnection (faults in libQt5Core) in that order. However, these may be faults may be secondary and not the root cause, there seems to be some activity in dmesg prior to the faults.

Hi,

I can propose a temporary workaround.

If I enter the following command on my system:

for i in 1 2 3 4 5 6 7; do echo 0 > /sys/devices/system/cpu/cpu$i/online; done; for i in 1 2 3 4 5 6 7; do echo 1 > /sys/devices/system/cpu/cpu$i/online; done

I don't see the bug (at least temporarily, but it seems to keep on).

It looks like the issue is related to parallel processes in threads.

@ Stuart, can you confirm the bug is no longer triggered with this workaround on your system?

Regards,

Olivier le Roy

Hi,

the above workaround

(for i in 1 2 3 4 5 6 7; do echo 0 > /sys/devices/system/cpu/cpu$i/online; done; for i in 1 2 3 4 5 6 7; do echo 1 > /sys/devices/system/cpu/cpu$i/online; done)

no longer works for me since I upgraded packages yesterday 2016/07/18.

I don't know if it is a coincidence and if that workaround was working by chance.

Regards,

Olivier le Roy

Created attachment 8236 [details]
Packages installed since July 22nd, triggering the bug on a stable cauldron

I can now confirm this bug too on my cauldron since yesterday's updates. Typing any accented character will crash Xorg.

I'm attaching a list of all packages I installed since yesterday (I rebooted overnight, and this morning installed some updates before noticing the bug, so I can't tell if yesterday's updates were the problem, or the ones from this morning).

Could be related to the new kernel, sddm, xinitrc, initscripts, libdrm.

Created attachment 8237 [details]
Remi's Xorg.0.log.old after a crash

Doesn't show much, but attaching for consistency. It seems to stop logging quite early, so no crash in it.

Created attachment 8238 [details]
Remi's dmesg.old from a boot that crashed

I have no /etc/X11/xorg.conf, but those two config files:

$ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "fr"
        Option "XkbModel" "pc105"
        Option "XkbOptions" "compose:rwin"
EndSection

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "DRI"    "3"
EndSection

I'm also using SDDM and Plasma 5. I don't manage to get a relevant output from journalctl so far, it seems not to keep logs from my previous boots... :(

Before SDDM shows up at boot, I see the systemd "Good luck :(" error telling that the X server couldn't start in time, and it's new from today, so probably related.

I've tested both 4.7.0-desktop-0.rc7.6.mga6 and 4.7.0-desktop-0.rc7.5.mga6, both seem to show the crash.

I'll try to revert some of the recent updates locally and see if I can narrow this down...

I changed my DM from SDDM to LightDM and rebooted, now I don't get crashes anymore neither in the DM nor in Plasma 5.

So there's something fishy going on in SDDM, potentially related to the changes Thomas pushed the last two days.

Created attachment 8245 [details]
List of packages installed during the July 23 batch of updates, fixing the bug

I no longer experience the bug since the batch of updates yesterday; I guess the issue was due to the new Xorg version and the necessary rebuild of all its reverse dependencies.

Hi,

I'm not completely certain it fixes the bug.

This bug comes and goes sometimes at random.

I thought it had disappeared on my system, and it comes again without changing anything.

Regards,

Olivier le Roy

Hi, 

It seems I've the same bug. 

Azerty keyboard, on an old Toshiba laptop. [è,é,à] by [shift]+[2,7,0] are concerned. 

Fred

oups 

[è,é,à] by [NO shift]+[2,7,0] 

And [ç] lowcase of [9]

I also see this bug with Plasma 5 with a fully up-to-date system. Typing "à" in the password field in sddm triggers the crash. Typing "à" in rpmdrake also triggers the crash. I didn't try other apps, before I was tired to have to reboot my machine all the time. When the GUI crashed, I logged in from the text-only command-line, typed "startx", but this didn't work, it crashed immediately again.

CC: (none) => LpSolit

Can't reproduce it on a keyboard with dead accents, where first the accent is typed and then letter you want to put it on. Tried in rpmdrake with 
èéëêàáäâìíïîòóöôùúüûçñõ.

I'm wondering whether there's a chance hitting this bug depends on the used keyboard. CC'ing Pablo.

CC: (none) => pablo

More info to what I said in comment 46: the GUI crashes every time you type e.g. "à" in konsole, firefox, rpmdrake, etc..., so the issue is not specific to an app.

When the GUI crashes, I log in as root from the text-only command line, and type "sddm". Now the GUI is back and I can type letters with an accent without any problem. Go figure! But the sound is gone, and I didn't manage to bring it back (i.e. without rebooting the machine). I hope this helps.

I can confirm this problem: M6 of july 22, fully updated yesterday. Installed Plasma with Dutch language and using AZERTY keyboard (quite standard in Belgium).
Created a new text file in ~/Documenten, opened it with Kwrite and typed "é".
Immediate crash of X and back to CLI login screen (in other words, the user has been thrown out).
Another side effect: I have in Systemsettings - keyboard the setting to put numlock always on (again quite standard use here with AZERTY keyboard), but no numlock service installed: after the crash, the numlock light on the keyboard is still on, but the numlock is not set. I suppose that is a consequence of the whole X been thrown out.

CC: (none) => herman.viaene

Did anyone with a non-Azerty keyboard hit this bug?

Keywords: (none) => NEEDINFO
Summary: Inputting accented characters triggers an xorg crash with recent cauldron kernels => Inputting accented characters (only on Azerty keyboards??) triggers an xorg crash with recent cauldron kernels

QWERTZ here.

(In reply to Frédéric Buclin from comment #51)
> QWERTZ here.

thx.


Azerty French
Azerty Belgian
Qwerz Swiss

Why don't e.g. Germans and Skandinavians reoort hitting it? They have letters with accents, too.

Summary: Inputting accented characters (only on Azerty keyboards??) triggers an xorg crash with recent cauldron kernels => Inputting accented characters triggers an xorg crash with recent cauldron kernels

Marja - I'm hitting the bug with a QWERTY keyboard.

(In reply to Stuart Morgan from comment #53)
> Marja - I'm hitting the bug with a QWERTY keyboard.

Thanks for the feedback. 


Next question for all:

Did this ever happen when using a different DM than SDDM?

(or when using no DM at all, so in a VT or text tty)

Tested with konsole as normal user: type "é" and immediate X crashes and user is thrown out (does this not indicate that there is more to it than a Plasma problem?).

@ Herman,

instead of in a konsole, could you try switching to tty3 with ctrl + alt + F3, login there and type an accented letter there. Of course that shouldn't kill your X in tty1, but if it does it would be good to know.

additionally, could you try switching to any other DM with drakdm, eg GDM, LXDM, LightDM, XDM and start a DE from there and type an accented letter?

@ LpSolit

(In reply to Frédéric Buclin from comment #48)
> More info to what I said in comment 46: the GUI crashes every time you type
> e.g. "à" in konsole, firefox, rpmdrake, etc..., so the issue is not specific
> to an app.
> 
> When the GUI crashes, I log in as root from the text-only command line, and
> type "sddm". Now the GUI is back and I can type letters with an accent
> without any problem. Go figure! But the sound is gone, and I didn't manage
> to bring it back (i.e. without rebooting the machine). I hope this helps.

This looks like very important information to me. What happens when you boot straight into RL3, and then start SDDM (or was that already what you did, rather than switching to a VT without rebooting)? 
Still no crashes but also no sound?

@ Nicolas
reassigning to you for now, because i haven't seen any indication that this happens outside sddm, too.

Assignee: tmb => mageia

I was able to reproduce the issue in IceWM but not from a TTY.

@ Marja
At your service:
Alternate tty: typing in "éèà<Enter> gives bash - command not found 
Install LXDM, login with LXDM, same crash as before.

But: reboot laptop, login with lxdm, no more crash.

I switched to lightdm and lxdm using drakdm, and I couldn't trigger the crash. Then I switched back to sddm, and I can no longer trigger the crash either. Moreover, this also fixed bug 18791. Could this be a bug in the mga6-sta1 DVD, which I originally used to install Mageia 6, where sddm was badly installed and/or configured? And maybe switching to another DM fixed the bad configuration or something like that?

@Frédéric: Do you confirm that after switching back to SDDM, the bug is still fixed even after a reboot?

I can confirm Frederic's outcome.
To resume:
Install M6 with Plasma with default sddm.
Reboot as many times as you want, the system crashes on text entry of accented characters inside the session booted.
Switch startup to lxdm - this requires the user to login again: same crash.
Reboot with lxdm: no problem anymore.
Reinstate sddm and reboot: not possible anymore to provoke the crash.

(In reply to Rémi Verschelde from comment #61)
> @Frédéric: Do you confirm that after switching back to SDDM, the bug is
> still fixed even after a reboot?

Yes. I also tried a complete shutdown + restart, and it still works fine. :)

Could you guys check if removing (renaming) /etc/sysconfig/desktop as mentioned in https://bugs.mageia.org/show_bug.cgi?id=18791#c18 triggers the bug again? The two bugs look quite similar.

Renamed /etc/sysconfig/desktop to /etc/sysconfig/desktop.testbug. No problem at that stage.
Rebooted (sddm is used): crash again.

Thanks Herman, so that confirms that this one and bug 18791 would be two manifestations of the same underlying bug (or at least, the same fix solves/hides both bugs).

Now that we have a documented way to reproduce the issue, I'll see if I can trigger it again too.

The next step for both bugs would be to retrieve backtraces of the sddm segmentation fault to try to solve this issue (not sure how to do this at this step though). It might also be the right moment to bring this issue upstream.

I can reproduce this bug, the first accented letter I type crashes my graphical display.

Hé hé

For your information, I've a small difference. 

I installed XDM, and immediatly logged in by XDM : no bug with XDM, then I switch to SDDM using drakconf and logged in with SDDM, at the first accented the bug occurs. :-(
I asked to reboot without changing the DM, so I log in with SDDM and now I don't have the bug.

Yes, that's the same workaround as described in https://bugs.mageia.org/show_bug.cgi?id=18791#c17 and later.

Hi,

the problem is still present on my Mageia 6 Cauldron system up to date as of 2016/09/20.

kernel 4.7.3-desktop-1.mga6 #1 SMP Wed Sep 7 19:18:25 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

libQt5Core.so.5.6.1

I didn't give a try to the XDM workaround.

Regards,

Olivier le Roy

Hi,

the problem is still present on my Mageia 6 Cauldron system up to date as of 2016/10/17.

- kernel 4.8.2-desktop-1.mga6 #1 SMP Sun Oct 16 17:59:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

- qt5core5-5.6.1-13.mga6

- sddm-0.14.0-7.mga6

I didn't give a try to the XDM workaround.

Regards,

Olivier le Roy

(In reply to David GEIGER from comment #23)
> Remove??
> 
> $ urpmq --whatrequires lib64ttspico0
> abuledu-microtexte
> leterrier-aller
> leterrier-calculment
> leterrier-memorise
> leterrier-mulot
> leterrier-racont
> lib64ttspico-devel
> lib64ttspico0
> speech-dispatcher
> svox-pico
> $
> 
> And I don't know how to fix this issue!
> 
> I can't repoduce this issue on my Cauldron.

Then I suggest we remove all those packages.
Or disable svox (which is done for eg: speech-dispatcher on other distros)

We're the only RPM distro to ship that broken svox-pico.

Debian has it (an older version) but in nonfree

According to them, we shouldn't package it in core (files w/o sources, ...)
=> "Due to the license restrictions described below, the packages are formally part of Debian's non-free category rather than Debian proper"
=> "The package is freely rebuildable and redistribuable"

Source RPM: kernel-4.7.0-desktop-0.rc7.6.mga6 => svox-pico-20120212-1.mga6 , sddm

Also, Olivier, could you please get a gdb backtrace of sddm when it segfaults?
Just:
1) Enable the "Core Release Debug" & "Core Updates Debug" media
2) install gpm, gdb, sddm-debuginfo & qtbase5-debuginfo
make sure the gpm service is enabled
3) as root from a console terminal (not a terminal in X11, eg: alt+ctrl+F5), run:
gdb /bin/sddm <pid_of_sddm> |tee -a LOG.18822.$$
4) then type "cont"
5) go back to X11, type an accent
6) when it freezes (b/c it has crashed and gdb is waiting), go back to the text console
7) run the "bt" command in gdb and copy paste the backtrace in vim
8) then attach the LOG.18822.* file you'll find to this bug report

(In reply to Thierry Vignaud from comment #72)

> Then I suggest we remove all those packages.
> Or disable svox (which is done for eg: speech-dispatcher on other distros)
> 
> We're the only RPM distro to ship that broken svox-pico.
> 
> Debian has it (an older version) but in nonfree
> 
> According to them, we shouldn't package it in core (files w/o sources, ...)
> => "Due to the license restrictions described below, the packages are
> formally part of Debian's non-free category rather than Debian proper"
> => "The package is freely rebuildable and redistribuable"

Why remove svox-pico?? and why you are saying it is broken?? 
this package has nothing to do here with the issue in this bug!

And svox works correctly.

CC: (none) => geiger.david68210

See comment #19

and you see comment #25

svox-pico is not at all the fault!

And I updated three months ago svox-pico to the latest git snapshot:

http://svnweb.mageia.org/packages?view=revision&revision=1041094

and synced patches with debian

Created attachment 8578 [details]
sddm crash gdb log

Interesting, it crashes in glib.
Could you get the backtrace again after intstalling glib2.0-debuginfo & glibc-debuginfo?

Source RPM: svox-pico-20120212-1.mga6 , sddm => sddm, glib2.0
CC: (none) => olav

Created attachment 8582 [details]
sddm crash gdb log

LOG.18822.5560

CC: (none) => olivier_le_roy
Attachment 8578 is obsolete: 0 => 1

humm it doesn't looks it segfaulted here.
Can you try "thread apply all bt" instead of "bt"?

Created attachment 8584 [details]
sddm crash gdb log

LOG.18822.5760

Attached is the requested log with the backtraces of the threads.

Remember to merge these patches:

https://github.com/sddm/sddm/commit/5fc7044ac1f3e32c9243e61732215576eea389e3

https://github.com/sddm/sddm/commit/5ea5eb06e3ece0a08ca0e631f1295d1cfe010476

https://github.com/sddm/sddm/commit/fb34fd4cc54182a8b14855b42695d6fdaf1f29ff

https://github.com/sddm/sddm/commit/38ce346ca9eb6f74c0fc8386deb336dc28c64df9

CC: (none) => ghibomgx

Hi,

I would like to mention that I have a strange behavior since yesterday 28/11 update of my Cauldron 6 system.

The X server no longer starts normally after the update.

I have found, by chance, a workaround to have X11 started.

In the grub boot menu, I edit the kernel boot command with 'e' add 'single' at the end of the kernel boot command, then 'CTRL + x' to boot.

Then, when I am asked to enter root password for maintenance, I enter the root password, and I logout with 'CTRL + D'.

Then, without any other command, the X server starts, and the KDE login page is displayed.

And, surprinsingly, the bug 'input accented characters' is no longer there when I had it systematically before.

This is still to be confirmed but I tried 2 / 2 with no 'accented caracters' causing the bug.

Other thing I would like to mention, is that by starting X11 this way, the 'sound' and 'USB' drives are functional.

I have the following packages versions installed:

- kernel 4.8.11-desktop-1.mga6 #1 SMP Sat Nov 26 10:05:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

- lib64qtcore4-4.8.7-14.mga6

- sddm-0.14.0-11.mga6

Regards,

Olivier le Roy

(In reply to Olivier LE ROY from comment #83)

This might be the same issue as reported in bug 19854.

>And, surprinsingly, the bug 'input accented characters' is no longer there when >I had it systematically before.

According to the change log for sddm-0.14.0-11.mga6, this bug should be fixed.

CC: (none) => gm2.asp

Fixed now indeed.

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