
| This forum is proudly powered by Scientific Linux 6 | SL website Download SL Help Search Members |
| Welcome Guest ( Log In | Register ) | Resend Validation Email |
![]() ![]() ![]() |
| thekat |
Posted: Mar 23 2012, 01:19 PM
|
|||
|
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.
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 |
|||
| AndrewSerk |
Posted: Mar 23 2012, 02:43 PM
|
|||
![]() SLF Moderator ![]() ![]() ![]() ![]() ![]() ![]() Group: Moderators Posts: 524 Member No.: 54 Joined: 14-April 11 |
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 |
|||
| thekat |
Posted: Mar 23 2012, 02:53 PM
|
|||
|
SLF Rookie ![]() Group: Members Posts: 19 Member No.: 35 Joined: 11-April 11 |
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 |
|||
| toracat |
Posted: Mar 24 2012, 01:35 PM
|
|||
![]() SLF Geek ![]() ![]() ![]() ![]() Group: Members Posts: 184 Member No.: 11 Joined: 10-April 11 |
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
|
|||
| zxq9 |
Posted: May 8 2012, 11:48 AM
|
|||||
![]() SLF Advocate ![]() ![]() ![]() ![]() ![]() Group: Members Posts: 367 Member No.: 611 Joined: 5-August 11 |
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). |
|||||
![]() |
![]() ![]() ![]() |