scientificlinuxforum.org QR code
Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> Kernel panic on upgrade
thekat
 Posted: Mar 23 2012, 01:19 PM
Quote Post


SLF Rookie
*

Group: Members
Posts: 19
Member No.: 35
Joined: 11-April 11









I recently tried to upgrade from SL 6.0 to SL 6.2 .
- yum clean all
- yum --releasever=6.2 update
- reboot

I have done this in the past with no incident on several boxes.
CODE

"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)".

I did boot off the the older kernel but my system is still listed in
/etc/redhat-release
Scientific Linux release 6.2 (Carbon)

Current working (6.0) kernel - 2.6.32-220.4.1.el6.x86_64
"6.2" bad kernel - kernel-2.6.32-220.7.1.el6.x86_64

My question
I can modify and stay with the kernel - 2.6.32-220.4.1.el6.x86_64 by
setting the default from 0 to 1 in grub.conf
or
is it better to 'yum remove kernel-2.6.32-220.7.1.el6.x86_64'
and 'wait for a newer kernel ?

rk

PM
^
AndrewSerk
 Posted: Mar 23 2012, 02:43 PM
Quote Post


SLF Moderator
******

Group: Moderators
Posts: 524
Member No.: 54
Joined: 14-April 11









QUOTE (thekat @ Mar 23 2012, 08:19 AM)

My question
I can modify and stay with the kernel - 2.6.32-220.4.1.el6.x86_64 by
setting the default from 0 to 1 in grub.conf
or
is it better to 'yum remove kernel-2.6.32-220.7.1.el6.x86_64'
and 'wait for a newer kernel ?

rk


Hi thekat,

Both methods are acceptable methods.

It is easy to change default from 0 to 1, but with this method you must remember to change it back to 0 after the next kernel update.

If you deciede to remove the kernel and not change the default ,you will want to add " exclude=kernel-2.6.32-220.7.1.el6.x86_64" to /etc/yum.conf so that the problem kernel is not reinstalled.

It is really up to you as to how to proceed, but i would prefer the second method for my systems.

Best of luck,

Andrew
PM
^
thekat
 Posted: Mar 23 2012, 02:53 PM
Quote Post


SLF Rookie
*

Group: Members
Posts: 19
Member No.: 35
Joined: 11-April 11









QUOTE (AndrewSerk @ Mar 23 2012, 02:43 PM)

Hi thekat,

Both methods are acceptable methods.

It is easy to change default from 0 to 1, but with this method you must remember to change it back to 0 after the next kernel update.

If you deciede to remove the kernel and not change the default ,you will want to add " exclude=kernel-2.6.32-220.7.1.el6.x86_64" to /etc/yum.conf so that the problem kernel is not reinstalled.

It is really up to you as to how to proceed, but i would prefer the second method for my systems.

Best of luck,

Andrew


Andrew,
Thanks for the quick response, I will error on the side of caution and add the "exclude" statement until I get time to spend more time on this

tk
PM
^
toracat
 Posted: Mar 24 2012, 01:35 PM
Quote Post


SLF Geek
****

Group: Members
Posts: 184
Member No.: 11
Joined: 10-April 11









QUOTE (thekat @ Mar 23 2012, 05:19 AM)

Current  working (6.0) kernel - 2.6.32-220.4.1.el6.x86_64
"6.2" bad kernel - kernel-2.6.32-220.7.1.el6.x86_64

I am slightly confused. kernel-2.6.32-220.4.1.el6 is a 6.2 kernel. If this was the last kernel before running the yum command, that would mean your kernel was already at the 6.2 level.

You mentioned you had done similar yum updates on other systems without an issue. Is there anything different / unique about the machine with the current trouble?


--------------------
ELRepo: repository specialized in hardware support for EL
PMUsers Website
^
zxq9
 Posted: May 8 2012, 11:48 AM
Quote Post


SLF Advocate
*****

Group: Members
Posts: 367
Member No.: 611
Joined: 5-August 11









QUOTE (toracat @ Mar 24 2012, 01:35 PM)
QUOTE (thekat @ Mar 23 2012, 05:19 AM)

Current  working (6.0) kernel - 2.6.32-220.4.1.el6.x86_64
"6.2" bad kernel - kernel-2.6.32-220.7.1.el6.x86_64

I am slightly confused. kernel-2.6.32-220.4.1.el6 is a 6.2 kernel. If this was the last kernel before running the yum command, that would mean your kernel was already at the 6.2 level.

You mentioned you had done similar yum updates on other systems without an issue. Is there anything different / unique about the machine with the current trouble?


Yes, this kernel build was poo, but only failed on systems that booted from SSDs. I discovered this while building some new systems we're testing SSDs on -- all of the hardware is identical to deployed systems which didn't have a problem with this kernel.

Our E350, A4, A8 and Phenom II systems using Hitachi 7200rpm 500Gb HDDs -- no problem
Same configuration with Intel 520 SSDs -- no boot
(We use the AMD drivers, but I tested both ways just in case)

There are some configuration differences on the SSD systems -- the i/o scheduler has been changed from the default, /tmp is in a tmpfs, swap is disabled, etc. On one system I went through each option and switched them all back until that system was completely vanilla with all options matching an HDD based system with the exception of creating a swap partition.

I never could resolve the issue, so I assume it was a problem with something in the way Intel 520s talk to the system -- which baffles me, because the 520 presents a standard "I'm a SATA disk" face to the system. Also, we are not using LVM on any of these systems (all tested were client systems).

The 13.1 kernel build works just fine again, so this problem with build 7.1 will likely remain a mystery, but its something to keep in mind (I wonder if anyone else had a similar experience and wrote about it somewhere? I've not kept up with TUV's bugzilla).
PMEmail PosterUsers Website
^
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll