| Summary: | impossibility to open firefox and thunderbird under kernel 4.14.20-1 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | peter lawford <petlaw726> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | doktor5000, kernel, lamikr, marja11, pterjan, shlomif, tmb |
| Version: | 6 | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | last kernel 4.14.20-1 | CVE: | |
| Status comment: | |||
| Attachments: | return of cat /proc/cpuinfo | ||
|
Description
peter lawford
2018-03-02 00:24:09 CET
Marja Van Waes
2018-03-02 21:53:55 CET
CC:
(none) =>
doktor5000, kernel, marja11 firefox starts and runs fine inside an mga6 x86-64 vm here with kernel 4.14.20 . Does the problem in a new mageia user account? CC:
(none) =>
shlomif (In reply to Shlomi Fish from comment #1) > firefox starts and runs fine inside an mga6 x86-64 vm here with kernel > 4.14.20 . Does the problem in a new mageia user account? no (In reply to peter lawford from comment #2) > (In reply to Shlomi Fish from comment #1) > > firefox starts and runs fine inside an mga6 x86-64 vm here with kernel > > 4.14.20 . Does the problem in a new mageia user account? > > no Do you mean that the problem does not happen in a new user? Can you try using strace?
Marja Van Waes
2018-03-03 21:05:44 CET
Keywords:
(none) =>
NEEDINFO I have old mga6 system updated with latest rpms and both the firefox and thunderbird opens ok for me. Maybe some other file is corrupted in your system. Does it help if you first try to rename the .thunderbird dir which contains the mail settings temporarily to something else and then start the thunderbird? CC:
(none) =>
lamikr Given the problem (illegal instruction), this is probably related to specific CPUs. Can you attach /proc/cpuinfo file? The strange part is that I would not expect the kernel to cause different userspace code to run. Are you using the same video drivers with the different kernels? CC:
(none) =>
pterjan Normally I'd agree with prerjan, but nowdays... It can be a fallout of the specte/meltdown fixes as there are changes all over cpu specific codepaths CC:
(none) =>
tmb solved! I have 2 mageia6 systems: the main one comes from updating mageia5, and the second one is a duplicate of the main one on another device (say a LVM based on a level5 mdadm-raid volume) using dump/restore and dracut through chroot, and I test the updates on the copy, and if everything is OK, I update to the main one. I suppose the copy was corrupted, due to bad dracut configuration, I've removed it and duplicate again (with changes on dracut) and now this bug no longer exists. Unfortunately, after updating, others bugs appeared, as update includes more than 71 packages, I can't experiment each one separately, no time for that the main new bug is that is seemed that after updating, mounting a lvm partition based on a level6 mdadm-raid volume freezes the system. I have found numerous others dysfunctions, but posting them would need too much time, I can't afford I think I'll soon migrate to kubuntu or mint really sorry I'm about to post the new bug Created attachment 10020 [details]
return of cat /proc/cpuinfo
(In reply to Pascal Terjan from comment #5) > Given the problem (illegal instruction), this is probably related to > specific CPUs. Can you attach /proc/cpuinfo file? > > The strange part is that I would not expect the kernel to cause different > userspace code to run. Are you using the same video drivers with the > different kernels? return of cat /proc/cpuinfo is attached here I suggest to close this bug (In reply to peter lawford from comment #7) > solved! > I have 2 mageia6 systems: the main one comes from updating mageia5, and the > second one is a duplicate of the main one on another device (say a LVM based > on a level5 mdadm-raid volume) using dump/restore and dracut through chroot, > and I test the updates on the copy, and if everything is OK, I update to the > main one. > I suppose the copy was corrupted, due to bad dracut configuration, I've > removed it and duplicate again (with changes on dracut) and now this bug no > longer exists. I'm glad it no longer exists. I understand this issue wasn't a bug. > Unfortunately, after updating, others bugs appeared, as update includes more > than 71 packages, I can't experiment each one separately, no time for that > I'm about to post the new bug bug 22798, right? I hope the other issues got solved! (In reply to peter lawford from comment #10) > I suggest to close this bug Thanks for all the feedback! As the reporter of this bug, you should have been able to close it yourself ;-) Resolution:
(none) =>
INVALID |