Bug 143554 - System won't boot after kernel update to 2.4.21-20 or 2.4.21-27
System won't boot after kernel update to 2.4.21-20 or 2.4.21-27
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-22 03:27 EST by Vlady
Modified: 2007-11-30 17:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:10:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The result from `sysreport' command ran on one of ours problematic Dell 2650 (163.56 KB, application/octet-stream)
2005-01-11 05:36 EST, Vlady
no flags Details

  None (edit)
Description Vlady 2004-12-22 03:27:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2)
Gecko/20040924

Description of problem:
We recently updated the kernels of two of our Linux servers (PE2550
and PE2650) to the latest 2.4.21-27 . Both systems have PERC 3/Di RAID
controllers. The RAID controller firmware version of the PE2550 is
2.8; the RAID controller firmware version of the PE2650 is 2.7.
When we rebooted the systems they didn't return back. Below is the log
from the console.

... [snip] ...

VFS: Mounted root (ext2 filesystem).
Red Hat nash version 3.5.13 starSCSI subsystem driver Revision: 1.00
ting
Loading scRed Hat/Adaptec aacraid driver (1.1.5-[2361])
AAC0: kernel 2.8.4 build 6092
A
 Loading sd_modAC0: monitor 2.8.4 build 6092
Ao module
LoadiAC0: bios 2.8.0 build 6092
Ag aacraidAC0: serial 65b010d2fafaf001
Ao module
AC0: ROMB RAID/SCSI mode enabled
AAC0: Non-DASD support enabled
scsi0 : percraid
blk: queue c6ea4218, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: DELL      Model: PERCRAID RAID5    Rev: V1.0
  Type:   Direct-Access                      ANSI SCSI revision: 02
blk: queue c6ea4018, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 106692864 512-byte hdwr sectors (54627 MB)
sda: Write Protect is off
Partition check:
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 >
Loading jbd.o moJournalled Block Device driver loaded
dule
Loading ext3.o module
Mounting kjournald starting.  Commit interval 5 seconds
/proc filesystemEXT3-fs: mounted filesystem with ordered data mode.

Creating block devices
Creating root device
Mounting root filesystem
Freeing unused kernel memory: 228k freed
INIT: version 2.85 booting
                Welcome to Red Hat 
                Press 'I' to enter interactive startup.
/etc/rc.d/rc.sysinit: line 74:    37 Segmentation fault     
/bin/dmesg -n $LOGL
EVEL
/etc/rc.d/rc.sysinit: line 89:    42 Segmentation fault     
/sbin/blockdev --fl
ushbufs /dev/ram0 >/dev/null 2>&1
Configuring kernel parameters:  [  OK  ]
/etc/rc.d/rc.sysinit: line 135:    46 Segmentation fault     
/sbin/hwclock $CLO
CKFLAGS
Setting clock  (localtime): Tue Dec 21 18:15:39 CET 2004 [  OK  ]
SettEXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,2), ing hostname
mb3nternal journ
al
.cmotd.com:  [FAILED]
Checking root filesystem
/dev/sda2: clean, 165872/626496 files, 936688/1251061 blocks
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda2 
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Activating swap partitions:  [FAILED]
/etc/rc.d/rc.sysinit: line 353:    86 Segmentation fault      rm -f
/etc/mtab~ /etc/mtab~~
/etc/rc.d/rc.sysinit: line 378:    92 Segmentation fault      rm -f
/lib/modules
/preferred /lib/modules/default
Finding module dependencies:  [  OK  ]
/sbin/devlabel: line 786: [: -ne: unary operator expected
/sbin/devlabel: line 899:   117 Segmentation fault      cat $temp_proc
>$LAST_LIST

... [snip] ...

After subsequent series of "Segmentation fault"s the systems become
irresponsible.

The only way to boot the systems was to load the old 2.4.21-15.0.4
kernels.

Version-Release number of selected component (if applicable):
kernel-2.4.21-27

How reproducible:
Always

Steps to Reproduce:
1. Install the 2.4.21-27 kernel on PE2250 or PE2650
2. Reboot the system with the recently installed kernel.
3.
    

Expected Results:  Normal boot

Additional info:
Comment 1 Tom Coughlan 2004-12-22 15:39:16 EST
Vlady,

Thank-you for separating this bug report from BZ 131703. 

To recap:

1. The U2+errata kernel (2.4.21-15.0.4) works.
2. U4 does not work.
3. (From your entry in BZ 131703) U4 with the aacraid_10102 driver
does not work. Note that the aacraid_10102 driver is the same as the
driver that works in U2. 
4. (Also from BZ 131703) "We had identical problems with PE1650 server
which has just SCSI controller (not RAID)".
5. The messages shown above indicate that the driver loaded and
configured the storage, apparently with no problem. 

So, I'm thinking that the problem is not in the aacraid driver. Please
confirm the above information, and also let us know which non-RAID
driver is involved in the PE1650 server failure.  

Comment 2 Vlady 2004-12-23 02:55:08 EST
Conformation:
1. No problems with 2.4.21-15.0.4 kernel.
2. Kernel 2.4.21-20 and above do not work.
3. The behaviour is identical when use aacraid and aacraid_10102
drivers in 2.4.21-20 kernel and above.
4. Yes, we had the same problem with non-RAID PE1650.
5. I also think the problem is not in the aacraid driver. I think the
problem is in the interaction between the kernel and the aacraid
and/or scsi drivers.
The RHEL 3.0 on our PE1650 server uses aic7xxx driver (the SCSI
controller is Adaptec aic7899 Ultra160 SCSI).

On both machines, during the boot time, any attempt an operation with
filesystem to be done (from /etc/rc.d/rc.sysinit) leaded to
"Segmentation fault". As a final result the machimes become irresponsible.
Comment 3 Vlady 2005-01-05 08:09:54 EST
Anybody working on fixing of this problem?
Comment 4 Tom Coughlan 2005-01-05 08:45:59 EST
I don't know what is causing this, so lets get more specific about the
steps you are taking.

> Steps to Reproduce:
> 1. Install the 2.4.21-27 kernel on PE2250 or PE2650

Have you updated the whole distribution, or just the kernel rpm? 

That does /etc/redhat-release say?

Are you switching from a working to a non-working system by just
booting a different kernel in grub.conf?
Comment 5 Vlady 2005-01-05 09:10:33 EST
cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 3 (Taroon Update 3)

Yes, i switched from non-working kernel to a working kernel by just
changing the defaultly loaded kernel in lilo.conf. Currently RHEL 3
"Update 3" system works with the lastest kernel from the "Update 2"
system.

As i said, for me the problem is in the kernels since 2.4.21-20 and
above. Something got changed in this kernel version which causes our
servers to freeze at boot.

We didn't have such problems with previous both RHEL 3 and kernel updates.
Comment 7 Tom Coughlan 2005-01-10 14:30:13 EST
Vlady,

Please run the "sysreport" command on your systrem and post the result.

Thanks.

Tom
Comment 8 Vlady 2005-01-11 05:36:40 EST
Created attachment 109598 [details]
The result from `sysreport' command ran on one of ours problematic Dell 2650

This is the report of `sysreport' command you requested.
Comment 9 Tom Coughlan 2005-01-11 18:27:30 EST
In the comments above, you said you were booting of aacraid, aacraid_10102, or
aic7xxx. 

In the sysreport, the system is booted off megaraid. There are some aic7xxx
ports present, but there is no storage configured on them. 

Is it possible that when you boot the newer kernels you are booting off a
different disk? or there is some device name change occurring?

Check this by watching the kernel boot messages that print before the sysinit
messages shown above. Compare the working and non-working kernels.

If that does not uncover the problem, try booting the new kernel in single user
mode (put "single" on the kernel command line). If you are able to get to a
prompt type: 

strace /bin/dmesg -n 3

and post the result.

Comment 10 Vlady 2005-01-12 03:11:27 EST
Sorry for the mistake. I sent sysreport results from a machine which uses
megaraid driver not from one which uses aacraid driver. The truth is the machine
with megaraid has the same problems as this one with aacraid. The "megaraid
machine" is Dell PE2650 and the "aacraid machine" is Dell PE2550. As I mentioned
in my previous messages the problem is not in the RAID driver, because we have
the same problems with non-RAID (but SCSI) Dell PE1650 and the problems exist
regardlress of the version of the RAID driver. I think the efforts, for
discovering of the problem, has to be directed to the SCSI subsystem not to the
aacraid driver.
Is there a majour change in the kernel code regarding SCSI subsystem from
2.4.21-20 kernels and above?
Comment 11 Tom Coughlan 2005-01-12 08:21:22 EST
There are very few changes in the SCSI code between 2.4.21-15 and 2.4.21-20. I
don't think the problem has anything to do with I/O. The trace you posted shows
the root filesystem being mounted and checked successfully, and there are no I/O
errors reported at all. The problem is at a higher level.

See if you can get an strace of one of the failing commands. 
Comment 12 Vlady 2005-01-13 05:26:56 EST
Below are the results from "strace" on /sbin/hwclock and strace on /bin/dmesg.
Both "strace" commands were executed with "-i" argument, in single user mode
under kernel 2.4.21-27 .
strace /sbin/hwclock had been stopped for some reason and i had to send it
"CONT" signal.
strace /bin/dmesg finished ok.


Strace RESUTS:

strace -i /bin/dmesg 2>&1

[007ddc60] execve("/bin/dmesg", ["/bin/dmesg"], [/* 11 vars */]) = 0
[007eec3d] uname({sys="Linux", node="(none)", ...}) = 0
[007ed6cb] brk(0)                       = 0x9286000
[007ee324] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or dir
ectory)
[007ee324] open("/etc/ld.so.cache", O_RDONLY) = 5
[007ee24b] fstat64(5, {st_mode=S_IFREG|0644, st_size=41313, ...}) = 0
[007eeb7d] old_mmap(NULL, 41313, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb75eb000
[007ee35d] close(5)                     = 0
[007ee324] open("/lib/tls/libc.so.6", O_RDONLY) = 5
[007ee3a4] read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200X\1"..., 
512) = 512
[007ee24b] fstat64(5, {st_mode=S_IFREG|0755, st_size=1571692, ...}) = 0
[007eeb7d] old_mmap(NULL, 1275340, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xa
50000
[007eeb7d] old_mmap(0xb82000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
, 5, 0x132000) = 0xb82000
[007eeb7d] old_mmap(0xb85000, 9676, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb85000
[007ee35d] close(5)                     = 0
[007eeb7d] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
 -1, 0) = 0xb75ea000
[007decab] set_thread_area({entry_number:-1 -> 6, base_addr:0xb75ea4e0, limit:10
48575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_pres
ent:0, useable:1}) = 0
[007eebc1] munmap(0xb75eb000, 41313)    = 0
[08048a5e] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
upeek: ptrace(PTRACE_PEEKUSER,364,48,0): No such process
[????????] +++ killed by SIGSEGV +++

--------------------------------------------------------------------------------------------------------------------------

strace -i /sbin/hwclock

[0024dc60] execve("/sbin/hwclock", ["/sbin/hwclock"], [/* 11 vars */]) = 0
[0025ec3d] uname({sys="Linux", node="(none)", ...}) = 0
[0025d6cb] brk(0)                       = 0x9f71000
[0025e324] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or dir
ectory)
[0025e324] open("/etc/ld.so.cache", O_RDONLY) = 5
[0025e24b] fstat64(5, {st_mode=S_IFREG|0644, st_size=41313, ...}) = 0
[0025eb7d] old_mmap(NULL, 41313, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb75ec000
[0025e35d] close(5)                     = 0
[0025e324] open("/lib/tls/libc.so.6", O_RDONLY) = 5
[0025e3a4] read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200X\1"..., 
512) = 512
[0025e24b] fstat64(5, {st_mode=S_IFREG|0755, st_size=1571692, ...}) = 0
[0025eb7d] old_mmap(NULL, 1275340, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0x2
85000
[0025eb7d] old_mmap(0x3b7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
, 5, 0x132000) = 0x3b7000
[0025eb7d] old_mmap(0x3ba000, 9676, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x3ba000
[0025e35d] close(5)                     = 0
[0025eb7d] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
 -1, 0) = 0xb75eb000
[0024ecab] set_thread_area({entry_number:-1 -> 6, base_addr:0xb75eb500, limit:10
48575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_pres
ent:0, useable:1}) = 0
[0025ebc1] munmap(0xb75ec000, 41313)    = 0
[0804f192] brk(0)                       = 0x9f71000
[0804f1a3] brk(0x9f7101a)               = 0x9f7101a
[0804f398] getpid()                     = 354
[0804f3b1] open("/proc/354/////////////exe", O_RDONLY) = 5
[0804f3d4] lseek(5, 12, SEEK_SET)       = 12
[0804f3e5] read(5, "\324\207\0\0", 4)   = 4
[0804f3fc] lseek(5, 0, SEEK_END)        = 37649
[0804f413] lseek(5, 34772, SEEK_SET)    = 34772
[0804f192] brk(0)                       = 0x9f7101a
[0804f1a3] brk(0x9f71b3d)               = 0x9f71b3d
[0804f465] read(5, "\351o\10\0\0\215v\0U\211\345\353\3X\353s\350\370\377\377"...
, 2877) = 2877
[0804f47a] close(5)                     = 0
[0804faa7] getppid()                    = 353
[0804fab1] fork()                       = 355
[0804fb23] waitpid(355,  <unfinished ...>
upeek: ptrace(PTRACE_PEEKUSER,354,48,0): No such process
[????????] +++ killed by SIGKILL +++
Comment 13 Tom Coughlan 2005-01-13 13:40:09 EST
For comparison, here is the output from an equivalent system that does not have
this problem. This is a U3 system with the kernel from U4, matching the
configuration above.

It seems the problems are around the munmap. I don't know why.

sh-2.05b# uname -a
Linux localhost.localdomain 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 2004
i686 i686 i386 GNU/Linux
sh-2.05b# more /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
sh-2.05b#
sh-2.05b# strace -i /bin/dmesg 2>&1
[0013dc60] execve("/bin/dmesg", ["/bin/dmesg"], [/* 9 vars */]) = 0
[0014ec3d] uname({sys="Linux", node="localhost.localdomain", ...}) = 0
[0014d6cb] brk(0)                       = 0x86e1000
[0014e324] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
[0014e324] open("/etc/ld.so.cache", O_RDONLY) = 3
[0014e24b] fstat64(3, {st_mode=S_IFREG|0644, st_size=86390, ...}) = 0
[0014eb7d] old_mmap(NULL, 86390, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75e3000
[0014e35d] close(3)                     = 0
[0014e324] open("/lib/tls/libc.so.6", O_RDONLY) = 3
[0014e3a4] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200X\1"...,
512) = 512
[0014e24b] fstat64(3, {st_mode=S_IFREG|0755, st_size=1568924, ...}) = 0
[0014eb7d] old_mmap(NULL, 1276876, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xa32000
[0014eb7d] old_mmap(0xb64000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x131000) = 0xb64000
[0014eb7d] old_mmap(0xb68000, 7116, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb68000
[0014e35d] close(3)                     = 0
[0014eb7d] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb75e2000
[0013ecab] set_thread_area({entry_number:-1 -> 6, base_addr:0xb75e24e0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
[0014ebc1] munmap(0xb75e3000, 86390)    = 0
[00b06c7b] brk(0)                       = 0x86e1000
[00b06c7b] brk(0x8702000)               = 0x8702000
[00b06c7b] brk(0)                       = 0x8702000
[00b0e804] syslog(0x3, 0x86e1038, 0x4008) = 16392
[00b0016e] fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0
[00b0623b] ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon
echo ...}) = 0
[00b0ab63] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb75f8000
[00b009fe] write(1, " IO-APIC physical APIC ID to 8 ."..., 39 IO-APIC physical
APIC ID to 8 ... ok.

and on it goes...

-----------------------------------

sh-2.05b# strace -i /sbin/hwclock
[00b8ac60] execve("/sbin/hwclock", ["/sbin/hwclock"], [/* 9 vars */]) = 0
[00b9bc3d] uname({sys="Linux", node="localhost.localdomain", ...}) = 0
[00b9a6cb] brk(0)                       = 0x9378000
[00b9b324] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
[00b9b324] open("/etc/ld.so.cache", O_RDONLY) = 3
[00b9b24b] fstat64(3, {st_mode=S_IFREG|0644, st_size=86390, ...}) = 0
[00b9bb7d] old_mmap(NULL, 86390, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75e2000
[00b9b35d] close(3)                     = 0
[00b9b324] open("/lib/tls/libc.so.6", O_RDONLY) = 3
[00b9b3a4] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200X\1"...,
512) = 512
[00b9b24b] fstat64(3, {st_mode=S_IFREG|0755, st_size=1568924, ...}) = 0
[00b9bb7d] old_mmap(NULL, 1276876, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xc89000
[00b9bb7d] old_mmap(0xdbb000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x131000) = 0xdbb000
[00b9bb7d] old_mmap(0xdbf000, 7116, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xdbf000
[00b9b35d] close(3)                     = 0
[00b9bb7d] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb75e1000
[00b8bcab] set_thread_area({entry_number:-1 -> 6, base_addr:0xb75e1500,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
[00b9bbc1] munmap(0xb75e2000, 86390)    = 0
[00d1c5d1] gettimeofday({1105644291, 749350}, NULL) = 0
[00d5dc7b] brk(0)                       = 0x9378000
[00d5dc7b] brk(0x9399000)               = 0x9399000
[00d5dc7b] brk(0)                       = 0x9399000
[00d3321a] getuid32()                   = 0
[00d57874] open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3
[00d57907] close(3)                     = 0
[00d5712e] stat64("/etc/adjtime", {st_mode=S_IFREG|0644, st_size=47, ...}) = 0

and on it goes...
Comment 15 Vlady 2005-01-14 03:15:57 EST
If this does matter, your system is AS but ours are ES. As i know there are
differences between the kernels of the AS and the ES. Even there are no
differences in the kernels, the problem in our systems exists and it has to be
solved.
Comment 16 Tom Coughlan 2005-01-14 08:16:26 EST
When lots of random programs are faulting it can mean that there is a problem
with glibc, or exec-shield.

Try re-installing the glibc rpms, and try booting the kernel with the parameter:

exec-shield=0
Comment 17 Vlady 2005-01-14 10:52:21 EST
Yes, that's it.
Booting kernel with "exec-shield=0" has solved the problem. Now one of our
systems runs 2.4.21-27 kernel without any thoughts for "Segmentation fault" :)

I want to thank all of you for the help and time spent on our problem.

I also want to suggest such valuable changes in the kernel like "exec-shield"
not to be allowed by default, when it's possible, because they could cause
serious troubles.
They have to be advertised, but their usage has to be left on the responsibility
of the servers' masters.

The "exec-shield" functionality is very great improvement of the Linux kernel,
but as it was proved, it's not yet well tested. It should not be enabled by
default, in the RedHat's stock kernels, becasue a lot of system adminstrators
(like me) trust in them.
Comment 24 RHEL Product and Program Management 2007-10-19 15:10:42 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.