View Issue Details

IDProjectCategoryView StatusLast Update
0006327CentOS-6yumpublic2015-05-25 20:24
Status newResolutionopen 
Product Version6.4 
Target VersionFixed in Version 
Summary0006327: Yum update to 6.4 caused Kernel PAnic
DescriptionPerformed yum update to 6.4 on office and home pc and after reboot both systems crash.

I'm fairly new to linux realm so if you work with me I can provide as much info to you as needed.

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid 1, comm: swapper Not tainted 2.6.32-358.2.1.e16.x86_64 #1

pic provided...


Steps To Reproducereboot without changing kernels
Tags6.4, kernel panic




2013-03-15 23:46


photo.JPG (99,628 bytes)
photo.JPG (99,628 bytes)


2013-03-15 23:51


crash.JPG (158,160 bytes)
crash.JPG (158,160 bytes)


2013-03-15 23:53

reporter   ~0016730

sorry added wrong pic first. Second pic shows error


2013-03-16 09:32

reporter   ~0016731

take a look at:

did you get any Fatal error before kernel panic?


2013-03-16 16:31

reporter   ~0016732

I have this same error, I encountered it after running yum update post 6.4 release. I have been able to boot by selecting the previous kernel.

I suspect that the new kernel isn't seeing my software RAID (created with mdadm) - my boot loader is located on a USB drive (not mounted), here is my filesystem:

Filesystem Size Used Avail Use% Mounted on
/dev/md2 65G 5.7G 56G 10% /
tmpfs 939M 100K 939M 1% /dev/shm
/dev/md1 194M 115M 69M 63% /boot
/dev/md127 917G 752G 165G 83% /home

I looked at the tickets that tarantinos posted but neither one seemed similar to this bug.


2013-03-16 19:58

reporter   ~0016734

Same problem/error message. Intel DX38BT motherboard. Software RAID disks. Shadowed root disk (raid1). Luckily previous kernel boots OK.

korora# cat mdadm.conf
# mdadm.conf written out by anaconda
AUTO +imsm +1.x -all
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=894d5184:e04dbb7c:38fced81:eb85a5ae
ARRAY /dev/md123 level=raid1 num-devices=2 UUID=863406bf:d22fafb2:8c43b85a:5280d3c5
ARRAY /dev/md125 level=raid1 num-devices=2 UUID=2fbf2f31:dca09261:360497cf:4d0053a4
ARRAY /dev/md127 level=raid1 num-devices=2 UUID=2497b812:3d7fe8ea:f80e9926:391f1d40
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=c28b5213:15e896db:564c280e:e82fd7b8

Let me know if I can supply any more info.


2013-03-16 21:18

reporter   ~0016735

Additional diagnostics: adding "debug" to kernel boot line shows:

md: Autodetecting RAID arrays
md: Scanned 0 and added 0 devices
md: autorun ...
md: ... autorun DOne.
VFS cannot open root device "UUID=xxxx..."

So problem is that the autodetect of the md raid arrays fails to detect anything resulting in no root partition being found.

Anyone any suggestions?
Thanks Alan


2013-03-17 01:28

reporter   ~0016736

tarantinos - no kernel errors after yum update. I basically performed sudo yum update, let it go and after a few minutes rebooted the pc since it was a new build I figured I should reboot. PC restarted to that error.


2013-03-17 01:34

reporter   ~0016737

Amcrae & wagstaff, I am currently using the below hardware

System Board - Gigabyte Z77MX-D3H
Intel Ivy Bridge core i3 35W dual core proc
16GB GSkill 12800 RAM
128GB Samsung Solid State Drive
1TB Samsung Data Drive.

no RAID configured yet but I was able to load the pc back into the previous Kernel to copy all of my conf files.

One note to make that I forgot to mention is that my homes directory is located on the data drive for instances like this and I didn't want a ton of read writes to the SSD drive


2013-03-17 01:36

reporter   ~0016738

tarantinos, also to note I looked at both of those issues before writing the original post and since none of those were resolutions to my issue I decided to post a new one.


2013-03-18 04:14

reporter   ~0016747

My problem cured by reinstalling kernel. I don't know why it went wrong the first time.
Fixed by the following:

# yum reinstall kernel-2.6.32-358.2.1.el6.x86_64


2013-03-18 04:20

reporter   ~0016748

amcrae - I wish I knew I could have done that. I copied all of my conf files and did a rebuild over the weekend, I needed it up and running. I really wish I knew that was possible instead of spending all weekend rebuilding the dang thing. Anyway's noted and will try for next time. I'm glad it worked for you :) I guess that's all a part of being a noob... I'm suprised no-one else has mentioned that in any google searches or other related issues.


2013-03-19 02:31

reporter   ~0016765

Hi All,

I can confirm that the kernel reinstall fixed my issue.

I did a bit of poking around to try and figure out what happened.

Before reinstalling the kernel I did a 'repocheck --list' against the most recent kernel and then did an md5sum against the list of files that it spit out. I reran the md5sum after reinstalling the kernel and when I diffed the lists:

[root@whitenoise ~]# diff kfilex.md5 kfileN.md5
> a3c9ce5951db1b76a8ac2362e53d198e /boot/initramfs-.6.32-358.2.1.el6.x86_64.img

It seems that I was missing the initramfs file after my first yum update. That's a real head scratcher, I used to trust yum more than I do right now...


2013-03-19 02:38

reporter   ~0016766

Sorry to double post, I meant that I did a repoquery --list not repocheck.


2013-03-19 08:02

administrator   ~0016767

something is not quite right there:
that file is not expected, and should be missing

corrupted FS or typo?
                ^___missing 2

did you run out of memory/disk space or your suffured from a interrupted update?


2013-03-19 19:59

reporter   ~0016775

I don't know what happened to that 2 - I checked the files and it's there, I copied and pasted it into the note; can't explain why it's missing from my post.

I did have a bit of a glitch when I did the yum update, my connection was dropped (gnome terminal running over a VNC session). However I jumped back in and did a yum-complete-transaction (I think it was already in the cleanup phase) and reviewed the logs. I didn't find any errors in the yum.log files.


2013-03-19 21:30

administrator   ~0016776

Wagstaff: I can only presume that the connection drop happened during the initramfs creation and caused your issue.. I would suggest a "rpm --verify -qa"
and a yum reinstall possibly damaged packages.


2013-03-20 06:03

reporter   ~0016778

I didn't get a chance yet to try the yum reinstall kernel but I did build a CentOS 6.3 VM in virtual box today and performed yum install update so it would update to 6.4 and it crashed again. Only this crash I was not able to revert back to the previous kernel. I will have to try it again tomorrow.


2013-03-24 21:39

reporter   ~0017001

Is there any update available on this problem?


2013-03-25 02:53

reporter   ~0017002

No updates as of a resolution, I tried to replicate it in VirtualBox but it crashed my VM and I was not able to load the previous Kernel. So there is definitely something wrong with the update from 6.3 to 6.4 from "YUM UPDATE" and I wish CentOS as awesome as the community is would test before releasing to verify the update is good. I'm still trying to get it to replicate so I can surely test the "YUM REINSTALL..."


2013-03-25 08:06

administrator   ~0017003

we don't have a reproducable test case... I have updated my 6.3 virtualbox to 6.4 without any issue. Share your virtuabox version/setup/kickstart?/, since you seem to have an continuing issue updating from 6.3 to 6.4.


2013-03-26 10:23

reporter   ~0017009

I have exactly then same problem: "YUM UPDATE" on a CentOS 6.3 and after reboot kernel panic.
My CentOS runs in a vitual machine (VMWARE).


2013-03-26 18:50

reporter   ~0017013


The VirtualBox Version 4.2.10
CentOS Version 6.3 Desktop
Yum install update to 6.4

I have tried updating the Kernel Headers first and I have tried just updating.
As of now everytime I try to update after reboot the VM goes to boot up but never gets to GUI or any Command Line. Just black screen.

When I originally ran yum install update both at my house and in the office I received the original error with pics posted at top on this thread. I have not been able to reproduce those errors as of trying with VB.




2013-03-26 22:18

reporter   ~0017015

I Seem to be having a similar issue with a Xen guest.

CentOS 6.4 x86_64 boots fine with the 2.6.32-358.0.1.el6.x86_64 kernel.

However after;

#yum update

Dependencies Resolved

 Package Arch Version Repository
 kernel x86_64 2.6.32-358.2.1.el6 updates 26 M
 initscripts x86_64 9.03.38-1.el6.centos.1 updates 937 k
 kernel-firmware noarch 2.6.32-358.2.1.el6 updates 11 M
 krb5-libs x86_64 1.10.3-10.el6_4.1 updates 760 k
 selinux-policy noarch 3.7.19-195.el6_4.3 updates 1.8 M
 selinux-policy-targeted noarch 3.7.19-195.el6_4.3 updates 2.8 M
 tzdata noarch 2013b-1.el6 updates 457 k

Transaction Summary
Install 1 Package(s)
Upgrade 6 Package(s)

Total download size: 44 M
#Is this ok [y/N]:y

# cat /boot/grub/grub.conf
title CentOS (2.6.32-358.2.1.el6.x86_64)
  root (hd0,0)
  kernel /boot/vmlinuz-2.6.32-358.2.1.el6.x86_64 console=hvc0 xencons=tty0 root=/dev/xvda1 ro crashkernel=auto
  initrd /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img
title vmlinuz-2.6.32-358.0.1.el6.x86_64
  root (hd0,0)
  kernel /boot/vmlinuz-2.6.32-358.0.1.el6.x86_64 console=hvc0 xencons=tty0 root=/dev/xvda1 ro
  initrd /boot/initramfs-2.6.32-358.0.1.el6.x86_64.img

The Xen guest fails to reboot. The following is the serial console output:

dracut: dracut-004-303.el6
udev: starting version 147
dracut: Starting plymouth daemon
dracut Warning: No root device "block:/dev/xvda1" found

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.

dracut Warning: Signal caught!

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-358.2.1.el6.x86_64 #1
Call Trace:
 [<ffffffff8150d248>] ? panic+0xa7/0x16f
 [<ffffffff81073ae2>] ? do_exit+0x862/0x870
 [<ffffffff81182965>] ? fput+0x25/0x30
 [<ffffffff81073b48>] ? do_group_exit+0x58/0xd0
 [<ffffffff81073bd7>] ? sys_exit_group+0x17/0x20
 [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b


2013-03-27 14:55

reporter   ~0017017

I Have the same boot problems but I think I've narrowed it down to the main boards embedded isci C600 SAS controller.

[steven@pmr-pos-tmp ~]$ uname -a
Linux pmr-pos-tmp 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[steven@pmr-pos-tmp ~]$ dmesg | grep isci
isci: Intel(R) C600 SAS Controller Driver - version 1.1.0-rh
isci 0000:03:00.0: driver configured for rev: 6 silicon
isci 0000:03:00.0: OEM parameter table found in OROM
isci 0000:03:00.0: OEM SAS parameters (version: 1.0) loaded (platform)
isci 0000:03:00.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
isci 0000:03:00.0: setting latency timer to 64
isci 0000:03:00.0: SCU controller 0: phy 3-0 cables: {short, short, short, short}
scsi6 : isci
isci 0000:03:00.0: SCU controller 1: phy 3-0 cables: {short, short, short, short}
scsi7 : isci
isci 0000:03:00.0: irq 80 for MSI/MSI-X
isci 0000:03:00.0: irq 81 for MSI/MSI-X
isci 0000:03:00.0: irq 82 for MSI/MSI-X
isci 0000:03:00.0: irq 83 for MSI/MSI-X

so sd[1,f] are detected:
[steven@pmr-pos-tmp ~]$ dmesg | grep sd
sd 6:0:3:0: [sdd] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 6:0:2:0: [sdc] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 6:0:0:0: [sda] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 6:0:1:0: [sdb] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 7:0:0:0: [sde] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 7:0:1:0: [sdf] 286749488 512-byte logical blocks: (146 GB/136 GiB)

[steven@pmr-pos-tmp ~]$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
      51206091 blocks super 1.2 [2/2] [UU]
md31 : active raid1 sdf1[1] sde1[0]
      71680902 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[0] sdb1[1]
      1028032 blocks [2/2] [UU]
md2 : active raid1 sdb3[1] sda3[0]
      91135649 blocks super 1.2 [2/2] [UU]
md22 : active raid1 sdc2[0] sdd2[1]
      71688966 blocks super 1.2 [2/2] [UU]
md32 : active raid1 sdf3[1] sde3[0]
      38129181 blocks super 1.2 [2/2] [UU]
md21 : active raid1 sdd1[1] sdc1[0]
      71680902 blocks super 1.2 [2/2] [UU]
unused devices: <none>

Yay! All raid disks came up and system boots!

Oh noes, let's boot kernel-2.6.32-358.2.1.el6.x86_64

For some strange reason I can't select, cut and paste on the spider that I'm using (even though the option exists) so I'll have to attach a snapshot of the screen when the system fails to boot and drops to the rdshell/dracut shell. An investigation of /dev while in the shell confirms that sd[a,f] do not exist.

I even downloaded the latest (?) drivers from Intel
and yum installed them but the same thing happened. 279.19 booted and 358.2 failed.

# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd1,1)
# kernel /vmlinuz-version ro root=/dev/md1
# initrd /initrd-[generic-]version.img
title CentOS (2.6.32-358.2.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-358.2.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 nomodeset KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rdshell
        initrd /initramfs-2.6.32-358.2.1.el6.x86_64.img
title CentOS (2.6.32-358.0.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-358.0.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 nomodeset KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rdshell
        initrd /initramfs-2.6.32-358.0.1.el6.x86_64.img
title CentOS (2.6.32-279.19.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-279.19.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 nomodeset KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rdshell
# kernel /vmlinuz-2.6.32-279.19.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 rhgb nomodeset KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM crashkernel=auto
        initrd /initramfs-2.6.32-279.19.1.el6.x86_64.img

What other information do you need?


2013-03-27 14:55


Centos6-4.jpg (102,487 bytes)
Centos6-4.jpg (102,487 bytes)


2013-04-02 01:54

reporter   ~0017071

Does anyone have a clue how to solve this problem? It seems as though it is being ignored.


2013-04-02 07:44

reporter   ~0017072

I think the /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img does not exist.

Please search that file or create it with:

# dracut --force '' 2..32-358.2.1.el6.x86_64

You can check at first your module-init-tools with:

yum upgrade module-init-tools

Hope that I could Help!


2013-04-02 08:40

reporter   ~0017074

Problem was on my pc with raid 5..
On other pc without raid all was fine.

I can confirm that the kernel reinstall fixed my issue too.

# yum reinstall kernel-2.6.32-358.2.1.el6.x86_64

boot fine..


2013-04-04 03:29

reporter   ~0017081

To all concerned, my kernel panic was caused by the old rpm/driver for the following device:

02:00.0 Ethernet controller: Atheros Communications Inc. AR8162 Fast Ethernet (rev 10)
    Subsystem: Lenovo Device 3979
    Flags: bus master, fast devsel, latency 0, IRQ 16
    Memory at d3900000 (64-bit, non-prefetchable) [size=256K]
    I/O ports at 2000 [size=128]
    Capabilities: [40] Power Management version 3
    Capabilities: [58] Express Endpoint, MSI 00
    Capabilities: [c0] MSI: Enable- Count=1/16 Maskable+ 64bit+
    Capabilities: [d8] MSI-X: Enable+ Count=16 Masked-
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [180] Device Serial Number ff-22-08-70-20-89-84-ff
    Kernel driver in use: alx
    Kernel modules: alx

I solved the problem by installing the following rpm/driver:

# rpm -qa|grep alx



I was able to boot to Centos 6.4 as follows:

# uname -a
Linux 2.6.32-358.2.1.el6.x86_64 0000001 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


Then the following device was not supported by Centos 6.4:

03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
    Subsystem: Broadcom Corporation Device 0587
    Flags: bus master, fast devsel, latency 0, IRQ 17
    Memory at d3800000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [58] Vendor Specific Information: Len=78 <?>
    Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [d0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [13c] Virtual Channel
    Capabilities: [160] Device Serial Number 00-00-3d-ff-ff-d6-c0-14
    Capabilities: [16c] Power Budgeting <?>
    Kernel driver in use: wl
    Kernel modules: wl, bcma

I later found the following URL: [^]

Here, there is a recipe that allows you to build a new rpm that lets the Broadcom 4313 do its work. When all else fails, follow instructions.

Good luck.


2013-04-28 05:13

reporter   ~0017332

same problem here. I was unfortunate because update makes three kernels not working anymore :

The way to solve the problem for me is to run
# yum reinstall kernel-2.6.32-358.2.1.el6.x86_64

at the rescue mode.
(noticing that dhcp in rescue mode may not automatically generate /etc/resolv.conf )


2013-11-24 18:47

reporter   ~0018396

Just an update.

Virtualbox: 4.3.2 r90405
Clean CentOS 6.4 and yum update.

All went right, or so it seems. After a reboot I get the Kernel Panic.
Revering to the old kernel and a
yum remove and reinstall of kernel-2.6.32-358.23.2.el6.x86_64
have resolved the issue.


2013-11-25 11:04

reporter   ~0018399

I have the same problem with two separate environments.

First, there's the system that I described in The 358.11.1 centosplus kernel works, but after I upgraded to 358.23.2 centosplus, I get this problem: root is on LVM and the LVM VGs cannot be found, resulting in a panic because there is no root. (Just to be sure, SCSI drives are found, indicating the dpt_i2o issue is not the problem.)

Second, there's a bunch of KVM guests that suffer from the same problem. The KVM is running on a CentOS 6 physical host. Virtual drives are "IDE Disk 1", backed by files on the physical host's filesystem.


2013-11-25 11:07

reporter   ~0018400

[root@kvmguest ~]# lsinitrd /boot/initramfs-2.6.32-279.19.1.el6.x86_64.img | grep lib/modules.*dm-|cut -f4- -d/|sort>/tmp/
[root@kvmguest ~]# lsinitrd /boot/initramfs-2.6.32-358.23.2.el6.x86_64.img | grep lib/modules.*dm-|cut -f4- -d/|sort>/tmp/
[root@kvmguest ~]# diff /tmp/ /tmp/
< kernel/drivers/md/dm-registry.ko
< kernel/drivers/md/dm-replicator.ko
< kernel/drivers/md/dm-repl-log-ringbuffer.ko
< kernel/drivers/md/dm-repl-slink-blockdev.ko

I wonder if the lack of these modules has anything to do with it, though.


2015-05-25 20:24

reporter   ~0023192

I still have the same problem on the kvm guests. The last kernel that will boot is 279.19.1. Any more recent version finds the SCSI drives, takes its sweet time with dracut not finding the root volume group, and eventually panics. New VMs on the same platform have no issue. Creating the environment from scratch with a handful of new VMs is a possibility, but a significant amount of work that seems unnecessary if I could just get a newer kernel to boot on these.

Issue History

Date Modified Username Field Change
2013-03-15 23:46 ZeroOnec New Issue
2013-03-15 23:46 ZeroOnec File Added: photo.JPG
2013-03-15 23:51 ZeroOnec File Added: crash.JPG
2013-03-15 23:52 ZeroOnec Tag Attached: 6.4
2013-03-15 23:52 ZeroOnec Tag Attached: kernel panic
2013-03-15 23:53 ZeroOnec Note Added: 0016730
2013-03-16 09:32 tarantinos Note Added: 0016731
2013-03-16 16:31 Wagstaff Note Added: 0016732
2013-03-16 19:58 amcrae Note Added: 0016734
2013-03-16 21:18 amcrae Note Added: 0016735
2013-03-17 01:28 ZeroOnec Note Added: 0016736
2013-03-17 01:34 ZeroOnec Note Added: 0016737
2013-03-17 01:36 ZeroOnec Note Added: 0016738
2013-03-18 04:14 amcrae Note Added: 0016747
2013-03-18 04:20 ZeroOnec Note Added: 0016748
2013-03-19 02:31 Wagstaff Note Added: 0016765
2013-03-19 02:38 Wagstaff Note Added: 0016766
2013-03-19 08:02 tru Note Added: 0016767
2013-03-19 19:59 Wagstaff Note Added: 0016775
2013-03-19 21:30 tru Note Added: 0016776
2013-03-20 06:03 ZeroOnec Note Added: 0016778
2013-03-24 21:39 lidstonesystems Note Added: 0017001
2013-03-25 02:53 ZeroOnec Note Added: 0017002
2013-03-25 08:06 tru Note Added: 0017003
2013-03-26 10:23 barghuse Note Added: 0017009
2013-03-26 18:50 ZeroOnec Note Added: 0017013
2013-03-26 22:18 colin Note Added: 0017015
2013-03-27 14:55 sconway Note Added: 0017017
2013-03-27 14:55 sconway File Added: Centos6-4.jpg
2013-04-02 01:54 lidstonesystems Note Added: 0017071
2013-04-02 07:44 nth1955 Note Added: 0017072
2013-04-02 08:40 agrisv Note Added: 0017074
2013-04-04 03:29 lidstonesystems Note Added: 0017081
2013-04-28 05:13 diablo465 Note Added: 0017332
2013-11-24 18:47 ct Note Added: 0018396
2013-11-25 11:04 infinitemho Note Added: 0018399
2013-11-25 11:07 infinitemho Note Added: 0018400
2015-05-25 20:24 infinitemho Note Added: 0023192