| Summary: | After a 507-package update on 25 December, Plasma desktop display is unusable. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Andrews <andrewsfarm> |
| Component: | RPM Packages | Assignee: | KDE maintainers <kde> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | release_blocker | CC: | bequimao.de, ed1, jan-bugs, jasperodus, jyri2000, mageia, mageia, marja11, maurice77, wilcal.int |
| Version: | Cauldron | Keywords: | 7beta1, 7beta2 |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.mageia.org/show_bug.cgi?id=24060 | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | Journal of bad desktop | ||
|
Description
Thomas Andrews
2018-12-25 22:45:10 CET
Manuel Hiebel
2018-12-25 22:56:10 CET
Assignee:
bugsquad =>
kde I can confirm this bug. I notice the same problem on my Asus Zenbook (64-bit). I think it is related to the update to KDE 18.12. I think that the package qtvirtualkeyboard5 was installed with this update that was not installed beforehand. Only KDE (and its login screen) is affected. I can use an Xfce session without problems, even use KDE applications in that environment. I found a discussion about a similar problem (the virtual keyboard on the login screen): https://forum.kde.org/viewtopic.php?f=252&t=143311 CC:
(none) =>
ed1 (In reply to Thomas Andrews from comment #0) > > There is a 32-bit M6 install on the hard drive, so I might be able to use > that to gather information - assuming I have detailed instructions of how to > do so. You might first want to try, in the bootloader screen, to add " 3" to the kernel parameters of the plasma-update install, to login in text mode. I'd first try to run "urpmi --auto-update", in case the KDE upgrade wasn't complete. If, after reboot, the issue persists, then you reboot again with (" 3" added) to fetch the logs of the previous boot As root: journalctl -b-1 > journalctl.txt If the above doesn't work, then I think you need a Mageia 7beta1 Live iso, because Mga6 used different compression for the logs and can't (IINM) handle the Mga7 journal log files. Please mount your installed Mga7 root partition. There's a directory with a very long hexadecimal name in /that/partition's/var/log/journal/ please run, as root, journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt and then attach journal.txt to this bug report. (Compress the journal with "xz journal.txt" if it's too large to attach.) CC:
(none) =>
marja11 Same here on a Asus K50J
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 09)
Subsystem: ASUSTeK Computer Inc. Device [1043:1862]
Kernel driver in use: i915
Kernel modules: i915
The upgrade was complete, and the KDE painel is unsuable. Another machine with AMD/ATI graphics looks ok.
The problem with the virtual keyboard only occurs with the Mageia theme. Breeze works ok.
UlrichCC:
(none) =>
bequimao.de It's become clear that we are dealing with two issues here, the virtual keyboard, and the display. I've heard from others that have only seen the keyboard problem, so that must be less hardware-specific, and probably should be split off into another bug report. The display problem, on the other hand, so far has only been seen on Intel graphics. On my system, the "videocard" is identified only as "Core Processor Integrated Graphics Controller," and it's using the Intel 810 or later" module. More specs on the processor: Intel Core i3 350M, 2.26GHz. Marja, I tried adding "3" to the kernel parameters, and the boot appeared to fail with a blank screen. Perhaps I didn't wait long enough. I shall try again, this time also removing "splash quiet" to see what I come up with. I have also been able to boot into "recovery mode," so perhaps I can get the log that way. Unfortunately, I have almost zero experience in working in "recovery mode." Replacing "splash quiet" with "3" results in a hung boot. After ""Starting Hold until boot process finishes up..." and "Starting Terminate Plymouth Boot Screen..." I see several messages concerning wlo1 and iwlwifi, ending with "IFWLOG: register target." There it sits, cursor blinking. Another issue, perhaps? Will come back to this later. For now, some family activities call for my attention. Created attachment 10605 [details]
Journal of bad desktop
This was created by logging in using "recovery mode."
In my case the flickering desktop is the same as in bug 24060 because the workaround mentioned there worked for me.
Ulrich Beckmann
2018-12-26 21:03:52 CET
See Also:
(none) =>
https://bugs.mageia.org/show_bug.cgi?id=24060 Using MCC in "recovery mode" to change the video driver to "modesetting" eliminated the display problem. Using "urpmi --auto-update" from within recovery mode did not find any updates waiting, but I don't believe I had an Internet connection in that mode. Once I booted to a "normal" desktop using the modesetting driver, MCC reported several Plasma-related updates waiting, one of them being sddm. Getting them now... The updates made no difference in this issue. The "Intel 810 or later" driver still messes up, while the modesetting driver is OK. Funky virtual keyboard is still there, too.
William Kenney
2018-12-27 00:42:06 CET
CC:
(none) =>
wilcal.int On real hardware, M7, Plasma, 64-bit Package(s) under test: Plasma My platform: Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115 Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset Integrated Graphics Processor - Intel HD Graphics support Audito chipset - Realtek ALC892, 7.1 channels Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600 lspci -k 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) Subsystem: Gigabyte Technology Co., Ltd Device d000 Kernel driver in use: i915 Kernel modules: i915 A really spectacular crash. Screwed the whole system up into a completely unusable format. It's been awhile since we've seen one this bad. Cool. For some reason the login screen turned into an on screen keyboard. I've never seen that before. I'll wait for this one to get resolved then do a netinstall to a blank drive to get going again. The M7 development was going so smoothly. We needed one or two of these to make it exciting again. In a Vbox client, M7, Mate, 64-bit Package(s) under test: Mate All seems to be fine with the desktop. I can update then auto reboot back to a usable Mate desktop. But, if I log out to the log in screen, regardless of its theme, the login screen is locked up. No virtual keyboard. lspci -k -------- 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) Subsystem: Gigabyte Technology Co., Ltd Device d000 Kernel driver in use: i915 Kernel modules: i915 On real hardware, M7, Plasma, 64-bit Works very nicely here after a netinstall to a blank drive: Intel Core i7-2600K Sandy Bridge 3.4GHz overclocked to 3.8GHz LGA 1155 95W Quad-Core GIGABYTE GA-Z68X-UD3-B3 LGA 1155 Intel Z68 SATA 6Gb/s USB 3.0 ATX Intel Motherboard GIGABYTE GV-N440D3-1GI GeForce GT 440 (Fermi) 1GB 128-bit DDR3 PCI Express 2.0 x16 RTL8111/8168B PCI Express 1Gbit Ethernet CORSAIR Vengeance 16GB (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800) OCZ Vertex 4 VTX4-25SAT3-128G 2.5" 128GB SATA III 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1) Subsystem: Gigabyte Technology Co., Ltd Device 3518 Kernel driver in use: nvidia Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia390 Updates, goes in and out of the desktop to the login screen, reboots cleanly back to a working disktop. On real hardware, M7, Plasma, 64-bit netinstall to my Intel: Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115 Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset Integrated Graphics Processor - Intel HD Graphics support Audito chipset - Realtek ALC892, 7.1 channels Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600 lspci -k 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) Subsystem: Gigabyte Technology Co., Ltd Device d000 Kernel driver in use: i915 Kernel modules: i915 platform. Installs cleanly. Boots to a completely unusable desktop. Well, here on my HP 450g2 Core i5 Probook with a UEFI-booted 64-bit Plasma Mageia-7 on real h/w, today's 590-package update had no detrimental effect, though neither of the Kmail & Kompozer problems has gone away.
$ lspci -k
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
Subsystem: Hewlett-Packard Company Device 2248
Kernel driver in use: bdw_uncore
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
Subsystem: Hewlett-Packard Company Device 2248
Kernel driver in use: i915
Kernel modules: i915
/\/\auriceCC:
(none) =>
maurice I have the on-screen keyboard, but have not noticed anything else out of the ordinary. Real hardware, Cauldron, Plasma, 64-bit System: Host: localhost Kernel: 4.19.12-desktop-2.mga7 x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.14.4 tk: Qt 5.12.0 wm: kwin_x11 dm: SDDM Distro: Mageia 7 mga7 Graphics: Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] driver: nvidia v: 410.78 bus ID: 01:00.0 chip ID: 10de:1c82 Display: x11 server: Mageia X.org 1.20.3 driver: nvidia,v4l compositor: kwin_x11 resolution: 1920x1080~60Hz OpenGL: renderer: GeForce GTX 1050 Ti/PCIe/SSE2 v: 4.6.0 NVIDIA 410.78 direct render: Yes CC:
(none) =>
jasperodus can you kill plasmashell and start it under konsole to see debugs ? CC:
(none) =>
mageia I uninstalled lib64qt5virtualkeyboard5 (and the dependent packages lib64qt5hunspellinputmethod5-5.12.0-1.mga7.x86_64 and qtvirtualkeyboard5-5.12.0-1.mga7.x86_64). Now the virtual keyboard on the login screen is gone. (In reply to Béat E from comment #19) > I uninstalled lib64qt5virtualkeyboard5 (and the dependent > packages lib64qt5hunspellinputmethod5-5.12.0-1.mga7.x86_64 > and qtvirtualkeyboard5-5.12.0-1.mga7.x86_64). Now the virtual keyboard on > the login screen is gone. The virtual keyboard problem was taken care of by a change in /etc/sddm.conf with the last update of sddm. Unfortunately, the user has to authorize the change before it could be applied. That was the "inspection" notice you should have seen after receiving that sddm update. If you did nothing, the new sddm.conf was saved as /etc/sddm.conf.rpmnew and your old sddm.conf is still being used. To use the new conf file, assuming you do have a /etc/sddm.conf.rpmnew, as root rename /etc/sddm.conf to something like sddm.conf.old, and then rename sddm.conf.rpmnew to sddm.conf. The virtual keyboard should not show after that. Those who install from newer isos won't see the problem at all. Unfortunately, the latest round of updates doesn't do anything to fix the Intel video problem on the Probook 6550b. Moreover, I decided to try updating a Core 2 Duo machine that is also using Intel graphics, but that hasn't been updated for a couple of weeks or so. Not only does that machine now exhibit the problem, it seems that while it looks like I can get into recovery mode as root, I'm not authorized to run MCC while there. So, I have no idea of how to change the video driver to modesetting so I can use the system again. Looks like a new install is in order, with a different DE, until we have new isos. (In reply to Thomas Andrews from comment #21) > So, I have no idea of how to change the video driver to modesetting so I can > use the system again. Looks like a new install is in order, with a different > DE, until we have new isos. If you can edit the file /etc/X11/xorg.conf, in the "Device" section change the line Driver "intel" to Driver "modesetting" Alternatively, you should have IceWM installed as well as Plasma - try using that to make the changes (it should appear in the drop-down list in the SDDM login screen). You could also try the workaround described in bug 24060 comment 3. CC:
(none) =>
mageia (In reply to Martin Whitaker from comment #22) > > If you can edit the file /etc/X11/xorg.conf, in the "Device" section change > the line > > Driver "intel" > > to > > Driver "modesetting" > Hmmm. That reminds me of something. A while back - I think with Mageia 4 - there was an update (a kernel? video driver? I dunno.) that "broke" KDE on some Intel display hardware. The fix/workaround was adding a line to xorg.conf. Something about the acceleration method as I recall, but I don't remember details. I do remember that the next release didn't need it any more. I wonder if something like that would help here? (In reply to Nicolas Lécureuil from comment #18) > can you kill plasmashell and start it under konsole to see debugs ? Messages are identical when running with/without the workaround. No obvious errors reported in the system and Xorg logs. Using kernel-linus makes no difference. Keywords:
NEEDINFO =>
(none) (In reply to Martin Whitaker from comment #22) > > If you can edit the file /etc/X11/xorg.conf, in the "Device" section change > the line > > Driver "intel" > > to > > Driver "modesetting" > > Alternatively, you should have IceWM installed as well as Plasma - try using > that to make the changes (it should appear in the drop-down list in the SDDM > login screen). > Merely changing xorg.conf from within a Mageia 6 install didn't do the trick - no idea why. IceWM seems to have problems too - several things not working - but I was able to click up a terminal and run MCC. Changed the video driver that way, and the problem went away. I will hold off on starting a bug report on the IceWM problems for now, probably waiting until this one is solved and new isos come out to see if they are still there.
JanKusanagi
2018-12-29 01:20:08 CET
CC:
(none) =>
jan-bugs (In reply to Martin Whitaker from comment #22) > > You could also try the workaround described in bug 24060 comment 3. That also eliminated the problem on both of my affected systems. A very big update to the M7 Repo today so I gave a Vbox client netinstall a go. Installs cleanly and boots to a working desktop. Lots of things work correctly, a big improvement from just a few days ago. For some reason the keyboard, not the mouse, becomes inoperative. And that for both a wireless ( Logitech ) keyboard and mouse, and a wired ( USB ) pair. Note. The mouse continues to work, the keyboard not. A reboot of the Client may, or may not, get the keyboard working again. Only to stop working. (In reply to Thomas Andrews from comment #26) > (In reply to Martin Whitaker from comment #22) > > > > You could also try the workaround described in bug 24060 comment 3. > > That also eliminated the problem on both of my affected systems. An interesting tidbit of information: I was installing Plasma on one of my nvidia340 (Geforce 9800 GT) systems from the Live iso to check something else out, and I happened to miss booting with the non-free driver, so I did the install with nouveau. During the first boot, when the install finished up, everything was OK. But when I booted into the system after getting over 1000 updates the display was showing symptoms very like those seen on Intel systems in this bug. On a hunch, I applied the workaround, and rebooted to a working desktop showing no symptoms whatsoever! Now I'm wondering what other older systems could be "fixed" with this workaround... Updates are still coming along, as is the nature of Cauldron. Over 100 this morning. If some of those updates might help with this bug, please let us know so that those of us who have applied the workaround can test by removing it again. Otherwise, I, for one, will leave the workaround in place, so that my systems remain usable. (In reply to Nicolas Lécureuil from comment #18) > can you kill plasmashell and start it under konsole to see debugs ? I tried this and got the following output $ plasmashell qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. As expected, still valid after an install from the Round 1 beta 2 isos. (We need a 7beta2 keyword) Using a blank area of a hard drive on one of my affected machines, I did a "standard" Plasma install from the 32-bit Beta 2 CI. After the reboot and login, Plasma was unusable. This time, instead of using the above workaround, I logged into IceWM, ran systemsettings5 from a terminal, and told it to change the compositor to XRender. That did the trick. Plasma was fine after that. The Compositor page of Mageia 6's System Settings GUI notes that OpenGL has crashed KWin in the past, and suggests the change to XRender as one alternative if it does. They say the cause is most likely a driver bug. But without knowing anything about such things, it seems to me strange that the same bug would suddenly appear in both the Intel and nouveau drivers, at the same time.
William Kenney
2019-01-06 15:24:02 CET
Priority:
Normal =>
release_blocker
William Kenney
2019-01-06 15:25:00 CET
Keywords:
(none) =>
7beta1
Thomas Andrews
2019-01-06 17:09:53 CET
Keywords:
(none) =>
7beta2 On real hardware, M7, Plasma, 64-bit
Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115
Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset
Integrated Graphics Processor - Intel HD Graphics support
Audito chipset - Realtek ALC892, 7.1 channels
Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600
[wilcal@localhost ~]$ lspci -k
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Subsystem: Gigabyte Technology Co., Ltd Device d000
Kernel driver in use: i915
Kernel modules: i915
Install using:
Mageia-7-beta2-Live-Plasma-x86_64.iso 1/4/19
eccafd237f551eeaf4829763142f38ae
Boots too an unstable Plasma desktop
fall back to login page
login with Icewm which is much more stable
open ~/.config/kwinrc with kwrite
Change
[Compositing]
OpenGLIsUnsafe=false
to
[Compositing]
OpenGLIsUnsafe=true
Log out of Icewm
Login to Plasma
Plasma desktop is now stable and usable.
Complete install and update and successfully boot back to a
stable and working desktop
Good news! It appears that a Plasma update currently being tested fixes this bug. As of Round 3 of the 7beta2 test isos, this bug has been resolved. Status:
NEW =>
RESOLVED |