CentOS - Apr 2015 - Kernel panic, CentOS 7.1503 fully updated, with executing gkrellm.

Just a heads up, since I know gkrellm is in EPEL and not in the main 
CentOS repos.  However, something fairly fundamental has changed, as 
prior to updating, gkrellm worked fine, but now every time I execute 
gkrellm the kernel panics.

I'm going to triage on a different machine, as the panic corrupted at 
least one system library used by nautilus, but rpm -Va is your friend in 
these situations, and yum reinstall is its close kin.  So I would prefer 
to duplicate on a burner machine, and I'll try to get a snapshot of the 
panic.

If anyone else wants to try to reproduce, simply try installing the 
current gkrellm from EPEL on a fully updated CentOS 7 machine and see if 
it panics on you.  I kindof hope it's local to my machine and its 
configuration (/home is LUKS, for instance), and it would be great if 
someone could verify that.

I can't duplicate this, but I'm also on 4.0.0-0.rc6.el7.elrepo.x86_64
which may make a difference.
Will try it on the stock kernel, too when I reboot next time.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Lamar Owen" <lowen at pari.edu>
> To: centos at centos.org
> Sent: Thursday, 2 April, 2015 06:04:01
> Subject: [CentOS] Kernel panic, CentOS 7.1503 fully updated,	with executing
gkrellm.
> Just a heads up, since I know gkrellm is in EPEL and not in the main
> CentOS repos.  However, something fairly fundamental has changed, as
> prior to updating, gkrellm worked fine, but now every time I execute
> gkrellm the kernel panics.
> 
> I'm going to triage on a different machine, as the panic corrupted at
> least one system library used by nautilus, but rpm -Va is your friend in
> these situations, and yum reinstall is its close kin.  So I would prefer
> to duplicate on a burner machine, and I'll try to get a snapshot of the
> panic.
> 
> If anyone else wants to try to reproduce, simply try installing the
> current gkrellm from EPEL on a fully updated CentOS 7 machine and see if
> it panics on you.  I kindof hope it's local to my machine and its
> configuration (/home is LUKS, for instance), and it would be great if
> someone could verify that.
> 
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

On 02-04-2015 02:04, Lamar Owen wrote:
> Just a heads up, since I know gkrellm is in EPEL and not in the main
> CentOS repos.  However, something fairly fundamental has changed, as
> prior to updating, gkrellm worked fine, but now every time I execute
> gkrellm the kernel panics.
>
> I'm going to triage on a different machine, as the panic corrupted at
> least one system library used by nautilus, but rpm -Va is your friend in
> these situations, and yum reinstall is its close kin.  So I would prefer
> to duplicate on a burner machine, and I'll try to get a snapshot of the
> panic.
>
> If anyone else wants to try to reproduce, simply try installing the
> current gkrellm from EPEL on a fully updated CentOS 7 machine and see if
> it panics on you.  I kindof hope it's local to my machine and its
> configuration (/home is LUKS, for instance), and it would be great if
> someone could verify that.
If it's that easy to reproduce, please grab the panic message or 
generate a vmcore through crashdump and report it at bugzilla.redhat.com 
against kernel component.

You may be using an EPEL application but kernel shouldn't be panicking 
like that, specially if you're running it as an user.

   Marcelo

On 04/02/2015 07:29 AM, Marcelo Ricardo Leitner wrote:
> If it's that easy to reproduce, please grab the panic message or 
> generate a vmcore through crashdump and report it at 
> bugzilla.redhat.com against kernel component.
>
Thanks for the pointer with some details.  I see that I have a bit to 
learn.  The first thing I need to do is reproduce it on other hardware.

I will say that I have experienced the same bug twice, but the first 
time I thought it was a botched yum update with CR enabled (and me 
having several packages installed from a mixed set of repos as well as 
some hand-built RPMs in there), and that was with / on ext4. This 
happened with / on xfs and an almost pristine install of the 20150228 
rolling ISO updated to 1503.  I use gkrellm as a quick visual dashboard 
of system load, and it is useful in that context. I also have it in my 
startup applications, so the kp happens immediately after logging in.  
(Both times with the same /home on ext4 over LUKS.)  The second time, 
nautilus would not start on a reboot/re-login due to corruption of one 
of its libraries (found in the 'tracker' package).  So I am a bit loath 
to hit this one again on my main machine, as I just don't have time this 
week for another reinstall.
> You may be using an EPEL application but kernel shouldn't be panicking 
> like that, specially if you're running it as an user.
>
Yeah, if gkrellm (run as a non-privileged user) can panic the kernel, a 
non-gui app hitting the same bits can too (unless it's related to the 
video card's driver).  Pairing a non-privileged userland kp witha a 
remote arbitrary code execution bug could be nasty.  That's why I still 
hope it's local to my machine.  But now to try to reproduce on other 
hardware.  (for reference, hardware on which I saw the bug is a Dell 
Precision M6500 with a Core i7-740QM and an AMD/ATI Firepro 7820M video, 
with / on a Samsung PM830 SSD)

On 04/02/2015 10:33 AM, Lamar Owen wrote:
>  That's why I still hope it's local to my machine.  But now to try
to
> reproduce on other hardware.  (for reference, hardware on which I saw 
> the bug is a Dell Precision M6500 with a Core i7-740QM and an AMD/ATI 
> Firepro 7820M video, with / on a Samsung PM830 SSD)
Ok, I can't reproduce on my Precision M4300 with a Core 2 Duo T9300 and 
nVidia Quadro 360M video.  However, I do notice some differences between 
my M6500's login screen and the login screen of the M4300, notably the 
CentOS logo at bottom center.  So, to do more digging......

On 02-04-2015 17:05, Lamar Owen wrote:
> On 04/02/2015 10:33 AM, Lamar Owen wrote:
>>  That's why I still hope it's local to my machine.  But now to
try to
>> reproduce on other hardware.  (for reference, hardware on which I saw
>> the bug is a Dell Precision M6500 with a Core i7-740QM and an AMD/ATI
>> Firepro 7820M video, with / on a Samsung PM830 SSD)
> Ok, I can't reproduce on my Precision M4300 with a Core 2 Duo T9300 and
> nVidia Quadro 360M video.  However, I do notice some differences between
> my M6500's login screen and the login screen of the M4300, notably the
> CentOS logo at bottom center.  So, to do more digging......
Thanks for doing all this testing but it's not really necessary in order 
to report the bug.. you know that, right?

If you can share the original backtraces, it already helps and someone 
may even point you to a fix if it's a known issue.

   Marcelo

On 04/02/2015 04:35 PM, Marcelo Ricardo Leitner wrote:
>
> If you can share the original backtraces, it already helps and someone 
> may even point you to a fix if it's a known issue.
>
>
Ok, I have the vmcore, but the debuginfo for kernel 
3.10.0-229.1.2.el7.x86_64 I can't find.  Found and installed for kernel 
3.10.0-123.13.2.el7.x86_64 but that doesn't help me troubleshoot the 
-229.1.2 kernel.....

On 04/02/2015 04:05 PM, Lamar Owen wrote:
> On 04/02/2015 10:33 AM, Lamar Owen wrote:
>>  That's why I still hope it's local to my machine.  But now to
try to
>> reproduce on other hardware.  (for reference, hardware on which I saw 
>> the bug is a Dell Precision M6500 with a Core i7-740QM and an AMD/ATI 
>> Firepro 7820M video, with / on a Samsung PM830 SSD)
> Ok, I can't reproduce on my Precision M4300 with a Core 2 Duo T9300 
> and nVidia Quadro 360M video.  However, I do notice some differences 
> between my M6500's login screen and the login screen of the M4300, 
> notably the CentOS logo at bottom center.  So, to do more digging......
>
It does reproduce on the M6500, but at least no corrupted libs this 
time.  Karanbir, Johnny, where might I find the -229.1.2 kernel's 
debuginfo package to get a backtrace from the vmcore I have from the panic?

On 03/04/15 00:18, Lamar Owen wrote:
> On 04/02/2015 04:35 PM, Marcelo Ricardo Leitner wrote:
>>
>> If you can share the original backtraces, it already helps and someone
>> may even point you to a fix if it's a known issue.
>>
>>
> 
> Ok, I have the vmcore, but the debuginfo for kernel
> 3.10.0-229.1.2.el7.x86_64 I can't find.  Found and installed for kernel
> 3.10.0-123.13.2.el7.x86_64 but that doesn't help me troubleshoot the
> -229.1.2 kernel.....
debuginfo's should be on their way, I know Johnny was working on that today.


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc

On 04/02/2015 07:52 PM, Karanbir Singh wrote:
> On 03/04/15 00:18, Lamar Owen wrote:
>> Ok, I have the vmcore, but the debuginfo for kernel 
>> 3.10.0-229.1.2.el7.x86_64 I can't find. Found and installed for 
>> kernel 3.10.0-123.13.2.el7.x86_64 but that doesn't help me 
>> troubleshoot the -229.1.2 kernel..... 
> debuginfo's should be on their way, I know Johnny was working on that
today.
Thanks for the update.  When they are available, I'll try it out.