| Summary: | 6_rc0: sddm segfaults in vendor VirtualBox after 4.8.7-desktop-1 kernel update | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bit Twister <bittwister2> |
| Component: | RPM Packages | Assignee: | KDE maintainers <kde> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | kernel, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | sddm-0.14.0-10.mga6.src.rpm | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 19782 | ||
| Attachments: | journalctl -b | grep sddm | ||
|
Description
Bit Twister
2016-11-13 19:23:01 CET
Created attachment 8657 [details]
journalctl -b | grep sddm
(In reply to Bit Twister from comment #0) > Description of problem: 6_rc0: > > sddm segfaults in vendor VirtualBox after 4.8.7-desktop-1 kernel update > > What else was then updated? Kernel updates never come alone ;-) (run e.g. "rpm -qa --last | head -n50 > last50.txt" or check the journalctl logs from around the kernel update) Does the problem get fixed if you run updates again? If not, do you happen to have an unhappy mirror? http://mirrors.mageia.org/status CC:
(none) =>
kernel, marja11 (In reply to Marja van Waes from comment #2) > What else was then updated? Kernel updates never come alone ;-) chromium-browser-54.0.2840.100-1.mga6.x86_64.rpm chromium-browser-stable-54.0.2840.100-1.mga6.x86_64.rpm cpupower-4.8.7-1.mga6.x86_64.rpm drakx-kbd-mouse-x11-1.18-1.mga6.x86_64.rpm drakx-kbd-mouse-x11-text-1.18-1.mga6.x86_64.rpm hexchat-2.12.3-1.mga6.x86_64.rpm kernel-desktop-4.8.7-1.mga6-1-1.mga6.x86_64.rpm kernel-desktop-devel-4.8.7-1.mga6-1-1.mga6.x86_64.rpm kernel-desktop-devel-latest-4.8.7-1.mga6.x86_64.rpm kernel-desktop-latest-4.8.7-1.mga6.x86_64.rpm kernel-doc-4.8.7-1.mga6.noarch.rpm kernel-source-4.8.7-1.mga6-1-1.mga6.noarch.rpm kernel-source-latest-4.8.7-1.mga6.noarch.rpm lib64git2_24-0.24.1-2.mga6.x86_64.rpm lib64rpm7-4.13.0-6.mga6.x86_64.rpm lib64rpmbuild7-4.13.0-6.mga6.x86_64.rpm libdrakx-kbd-mouse-x11-1.18-1.mga6.x86_64.rpm python2-rpm-4.13.0-6.mga6.x86_64.rpm rpm-4.13.0-6.mga6.x86_64.rpm rpm-build-4.13.0-6.mga6.x86_64.rpm x11-driver-video-intel-2.99.917-30.mga6.x86_64.rpm > Does the problem get fixed if you run updates again? Nope. > If not, do you happen to have an unhappy mirror? No way, Methodology is pull_updates on node wb. ssh tb, pull_updates pull_updates rsyncs rpms from wb. On TestBed (tb) install_updates reboot. Ok, launch Virtualbox on wb and then vb. pull_updates, rsyncs wb rpms to vb. install_updates and I reboot and it fails. On wb, I run install_updates, reboot and all works. Same set of rpms used where applicable.
Bit Twister
2016-11-15 10:44:02 CET
Severity:
normal =>
critical $ uname -r 4.8.9-desktop-1.mga6 Workaround: add nomodeset to kernel line and remove any vga=xxx argument.
Bit Twister
2016-11-25 04:55:19 CET
Blocks:
(none) =>
19782 removed nomodeset and added vga=791 back to kernel boot line. sddm no longer segfaulta and I do have a working display in runlevel 5. Sorry forgot to mark this resolved. Status:
NEW =>
RESOLVED Even if there's a workaround, it's still segfaulting in the other case so the bug is not fixed. Status:
RESOLVED =>
REOPENED (In reply to Samuel Verschelde from comment #7) > Even if there's a workaround, it's still segfaulting in the other case so > the bug is not fixed. You need to provide the "other case" so we know what you are talking about. All suggested kernel arguments to date did not work until I removed vga=xxx. I provide vga=xxx on all my installs host and guest alike. With the latest sddm update I no longer added any of the suggested arguments and vga=792 went back to working in my vb guests. Current grub2 kernel arguments are built from $ grep -i cmd /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT=" noiswmd" GRUB_CMDLINE_LINUX="ipv6.disable=1 audit=0 vga=792" GRUB_CMDLINE_LINUX= line is generated by my install script. Maybe I misread your comments. I though you found a workaround but that the initial segfault was still there. It's apparently not true, so closing again. Status:
REOPENED =>
RESOLVED |