Description of problem: it's impossible to open firefox and thunderbird-52.6.0-1.mga6 under kernel-(desktop, server)-4.14.20-1: here below the return of the commands: [alain4@mag6 ~]$ firefox Instruction non permise (core dumped) [alain4@mag6 ~]$ thunderbird Instruction non permise (core dumped) with kernel-(desktop, server)-4.14.18-1, these commands get no return, they simply work then with kernel 4.14.20-1, these main applications don't work Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
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?
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) => INVALIDStatus: NEW => RESOLVED