On 03/12/2013 04:23 PM, lists-centos wrote:
------------ Original Message ------------
Date: Tuesday, March 12, 2013 04:05:28 PM -0700 From: Emmett Culley emmett@webengineer.com To: centos@centos.org Cc: Subject: Re: [CentOS] Kernel panic after update to 6.4
On 03/12/2013 01:48 PM, Akemi Yagi wrote:
On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley emmett@webengineer.com wrote:
After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to update the host as well. And it failed to boot.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is not out yet. Where did you get this one from ??? Did you build it yourself?
Akemi
I did yum update --enablerepo=epel. I just checked and it appears that kernel was from the updates repo:
[~]# yum list kernel Installed Packages kernel.x86_64 2.6.32-279.9.1.el6 @updates kernel.x86_64 2.6.32-279.14.1.el6 @updates kernel.x86_64 2.6.32-279.19.1.el6 @updates kernel.x86_64 2.6.32-279.22.1.el6 @updates kernel.x86_64 2.6.32-358.0.1.el6 @updates
[~]# rpm -qa |grep kernel abrt-addon-kerneloops-2.0.8-15.el6.centos.x86_64 kernel-2.6.32-279.19.1.el6.x86_64 dracut-kernel-004-303.el6.noarch kernel-devel-2.6.32-279.14.1.el6.x86_64 kernel-2.6.32-279.14.1.el6.x86_64 kernel-devel-2.6.32-279.22.1.el6.x86_64 kernel-headers-2.6.32-358.0.1.el6.x86_64 kernel-firmware-2.6.32-358.0.1.el6.noarch kernel-2.6.32-358.0.1.el6.x86_64 kernel-devel-2.6.32-279.19.1.el6.x86_64 kernel-devel-2.6.32-358.0.1.el6.x86_64 kernel-2.6.32-279.9.1.el6.x86_64 libreport-plugin-kerneloops-2.0.9-15.el6.centos.x86_64 kernel-2.6.32-279.22.1.el6.x86_64 kernel-devel-2.6.32-279.9.1.el6.x86_64
This is from a VM that succeeded with the update to the "359" kernel. There are three more like that.
Emmett
You are giving conflicting information.
You indicated that the kernel that you are getting the panic on is:
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
i.e., ...358.2.1
What you are showing as available from @updates and installed in the VM that is working is:
kernel.x86_64 2.6.32-358.0.1.el6 @updates
kernel-2.6.32-358.0.1.el6.x86_64
i.e., ...358.0.1
RedHat released ...358.2.1 earlier today, but I haven't seen centos announce its release yet, and it's not available from the centos repositories as of a few moments ago. So, the VM that is ok is using ...358.0.1, the centos released kernel. The one that is panic would appear to have come from elsewhere.
Also note, it's the "358", not "359" kernel:
This is from a VM that succeeded with the update to the "359" kernel. There are three more like that.
Yes, kernel "358". the "359" was a typo. And... the kernel panic lines were transcribed for a photo I took of the screen after the failed boot. On second look I see that the version is 2.6.32-358.0.1.el6.x86_64.
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=epel on two of five machines, one of which is the host for the three VM's that succeeded and the one that failed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails on that kernel, on both the host and the VM. I suppose the good thing is that it happened on a VM guest that is not critical, so I don't have to experiment with the host that has four important guests running on it.
Any ideas?
Emmett
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=epel on two of five machines, one of which is the host for the three VM's that succeeded and the one that failed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails on that kernel, on both the host and the VM. I suppose the good thing is that it happened on a VM guest that is not critical, so I don't have to experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently. When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=6304
Just today kernel 2.6.32-358.2.1 became available. The problem is still present, but only on the same one machine.
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=epel on two of five machines, one of which is the host for the three VM's that succeeded and the one that failed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails on that kernel, on both the host and the VM. I suppose the good thing is that it happened on a VM guest that is not critical, so I don't have to experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently. When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=6304
Just today kernel 2.6.32-358.2.1 became available. The problem is still present, but only on the same one machine.
What does this command say:
rpm -q device-mapper
On 2013-03-13, Johnny Hughes johnny@centos.org wrote:
(...)
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=3Depel on two of five machines, one of =
which is the host for the three VM's that succeeded and the one that fail= ed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the p=
roper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails=
on that kernel, on both the host and the VM. I suppose the good thing i= s that it happened on a VM guest that is not critical, so I don't have to= experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently. When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=3D6304
Just today kernel 2.6.32-358.2.1 became available. The problem is still=
present, but only on the same one machine.
What does this command say:
rpm -q device-mapper
The output is
device-mapper-1.02.77-9.el6.i686
Ditto on the machines which are *not* affected.
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=epel on two of five machines, one of which is the host for the three VM's that succeeded and the one that failed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails on that kernel, on both the host and the VM. I suppose the good thing is that it happened on a VM guest that is not critical, so I don't have to experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently. When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=6304
Just today kernel 2.6.32-358.2.1 became available. The problem is still present, but only on the same one machine.
This file exists in the kernel: /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/dm-mod.ko
Somehow it seems that in some machines it is not making it into the initrd.
On 03/13/2013 05:17 PM, Johnny Hughes wrote:
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=epel on two of five machines, one of which is the host for the three VM's that succeeded and the one that failed, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fails on that kernel, on both the host and the VM. I suppose the good thing is that it happened on a VM guest that is not critical, so I don't have to experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently. When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=6304
Just today kernel 2.6.32-358.2.1 became available. The problem is still present, but only on the same one machine.
This file exists in the kernel: /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/dm-mod.ko
Somehow it seems that in some machines it is not making it into the initrd.
Try this command where the kernel is installed and not booting (when booted into a kernel that works):
lsinitrd /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img | grep dm-mod
(if you have one of the other 358 kernels installed, use that version instead of2.6.32-358.2.1.el6.x86_64 )
On 2013-03-13, Johnny Hughes johnny@centos.org wrote:
(...)
On 03/13/2013 05:17 PM, Johnny Hughes wrote:
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=3Depel on two of five machines, one of=
which is the host for the three VM's that succeeded and the one that fai= led, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the =
proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fail=
s on that kernel, on both the host and the VM. I suppose the good thing = is that it happened on a VM guest that is not critical, so I don't have t= o experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently.=
When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=3D6304
Just today kernel 2.6.32-358.2.1 became available. The problem is stil=
l
present, but only on the same one machine.
This file exists in the kernel: /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/dm-mod.ko
Somehow it seems that in some machines it is not making it into the ini=
trd.
Try this command where the kernel is installed and not booting (when booted into a kernel that works):
lsinitrd /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img | grep dm-mod
(if you have one of the other 358 kernels installed, use that version instead of2.6.32-358.2.1.el6.x86_64 )
Here you go:
$ uname -r && lsinitrd /boot/initramfs-2.6.32-358.2.1.el6.i686.img | grep dm-mod 2.6.32-279.22.1.el6.i686 -rwxr--r-- 1 root root 106212 Mar 13 17:11 lib/modules/2.6.32-358.2.1.el6.i686/kernel/drivers/md/dm-mod.ko
So the module appears to be present in the initrd.
The only distinguishing feature I can think of in the machine that is failing is that it has a solid-state drive. Relevant?
On 03/14/2013 05:17 AM, Liam O'Toole wrote:
On 2013-03-13, Johnny Hughes johnny@centos.org wrote:
(...)
On 03/13/2013 05:17 PM, Johnny Hughes wrote:
On 03/13/2013 04:19 PM, Liam O'Toole wrote:
On 2013-03-13, Emmett Culley emmett@webengineer.com wrote:
(...)
So let's start again.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1
After yum upgrade --enablerepo=3Depel on two of five machines, one of=
which is the host for the three VM's that succeeded and the one that fai= led, just as the host.
I have a screen shot of that VM's boot failure, but I don't know the =
proper way to include it in a post.
I've uninstalled that kernel and ran yum upgrade again, it still fail=
s on that kernel, on both the host and the VM. I suppose the good thing = is that it happened on a VM guest that is not critical, so I don't have t= o experiment with the host that has four important guests running on it.
Any ideas?
Emmett
I saw this problem on one machine I upgraded from 6.3 to 6.4 recently.= When I boot it in verbose mode I see the following messages:
dracut: /proc/misc: No entry for device-mapper found dracut: Failure to communicate with kernel device-mapper driver
which led me to the following bug report:
http://bugs.centos.org/view.php?id=3D6304
Just today kernel 2.6.32-358.2.1 became available. The problem is stil=
l
present, but only on the same one machine.
This file exists in the kernel: /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/dm-mod.ko
Somehow it seems that in some machines it is not making it into the ini=
trd.
Try this command where the kernel is installed and not booting (when booted into a kernel that works):
lsinitrd /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img | grep dm-mod
(if you have one of the other 358 kernels installed, use that version instead of2.6.32-358.2.1.el6.x86_64 )
Here you go:
$ uname -r && lsinitrd /boot/initramfs-2.6.32-358.2.1.el6.i686.img | grep dm-mod 2.6.32-279.22.1.el6.i686 -rwxr--r-- 1 root root 106212 Mar 13 17:11 lib/modules/2.6.32-358.2.1.el6.i686/kernel/drivers/md/dm-mod.ko
So the module appears to be present in the initrd.
The only distinguishing feature I can think of in the machine that is failing is that it has a solid-state drive. Relevant?
Maybe ... try this (everything done as root):
Boot on a kernel that works and do this:
1. Backup you current initrd:
cp -a /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img.bak
2. Go to this directory:
cd /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/
3. Figure out the md modules loaded in the old kernel:
lsmod | grep dm_
in my case, that output would be this:
[root@localhost md]# lsmod | grep dm_ dm_round_robin 2525 0 dm_multipath 17756 1 dm_round_robin dm_mirror 14133 0 dm_region_hash 12085 1 dm_mirror dm_log 9930 2 dm_mirror,dm_region_hash dm_mod 82839 12 dm_multipath,dm_mirror,dm_log
(note, dm-mod and dm_mod are the same thing)
5. Do an file list and make sure all the modules you need to include (in my case the 6 in column 1):
ls
Note: make sure all the modules are listed ad you see the file names (should be for me: dm-round-robin.ko, dm-multipath.ko, dm-mirror.ko, dm-region-hash.ko, dm-log.ko, dm-mod.ko)
4. Create a new initrd with all the relevant md modules preloaded (in my case, this command line ... preload only the modules you need from your list .. again, have to do this as root):
mkinitrd -f --preload=dm_round_robin --preload=dm_multipath --preload=dm_mirror --preload=dm_region_hash --preload=dm_log --preload=dm_mod /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img 2.6.32-358.2.1.el6.x86_64
Note: The above mkinitrd command (and all the other commands) should be entered all on one line, I am sure it will wrap when posted.
5. This may not work, because there may need to be some other things loaded that are not, like the disc controller's kernel module driver, etc. What I think is going on is either something has been removed from this kernel that existed before ... OR ... something is being mis-detected with this kernel on your machine.
On 2013-03-14, Johnny Hughes johnny@centos.org wrote:
(...)
Maybe ... try this (everything done as root):
Boot on a kernel that works and do this:
- Backup you current initrd:
cp -a /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img.bak
OK.
- Go to this directory:
cd /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/
For me the corresponding directory is /lib/modules/2.6.32-358.2.1.el6.i686/kernel/drivers/md.
- Figure out the md modules loaded in the old kernel:
lsmod | grep dm_
in my case, that output would be this:
[root@localhost md]# lsmod | grep dm_ dm_round_robin 2525 0 dm_multipath 17756 1 dm_round_robin dm_mirror 14133 0 dm_region_hash 12085 1 dm_mirror dm_log 9930 2 dm_mirror,dm_region_hash dm_mod 82839 12 dm_multipath,dm_mirror,dm_log
(note, dm-mod and dm_mod are the same thing)
In my case I have:
# lsmod | grep dm_ dm_mirror 11678 0 dm_region_hash 9609 1 dm_mirror dm_log 8322 2 dm_mirror,dm_region_hash dm_mod 66925 8 dm_mirror,dm_log
- Do an file list and make sure all the modules you need to include
(in my case the 6 in column 1):
ls
Note: make sure all the modules are listed ad you see the file names (should be for me: dm-round-robin.ko, dm-multipath.ko, dm-mirror.ko, dm-region-hash.ko, dm-log.ko, dm-mod.ko)
Yes, all are present:
# ls dm*.ko dm-bufio.ko dm-log-userspace.ko dm-queue-length.ko dm-service-time.ko dm-crypt.ko dm-memcache.ko dm-raid45.ko dm-snapshot.ko dm-delay.ko dm-mirror.ko dm-raid.ko dm-thin-pool.ko dm-flakey.ko dm-mod.ko dm-region-hash.ko dm-zero.ko dm-log.ko dm-multipath.ko dm-round-robin.ko
- Create a new initrd with all the relevant md modules preloaded (in
my case, this command line ... preload only the modules you need from your list .. again, have to do this as root):
mkinitrd -f --preload=3Ddm_round_robin --preload=3Ddm_multipath --preload=3Ddm_mirror --preload=3Ddm_region_hash --preload=3Ddm_log=20 --preload=3Ddm_mod /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img 2.6.32-358.2.1.el6.x86_64
Note: The above mkinitrd command (and all the other commands) should be entered all on one line, I am sure it will wrap when posted.
(Indeed it did wrap.) The command I used was
mkinitrd -f --preload=dm_mirror --preload=dm_region_hash --preload=dm_log --preload=dm_mod /boot/initramfs-2.6.32-358.2.1.el6.i686.img 2.6.32-358.2.1.el6.i686
That produced a file of similar size to the original:
# ls -l /boot/initramfs-2.6.32-358.2.1.el6.i686.img* -rw-r--r--. 1 root root 15450686 Mar 14 15:13 /boot/initramfs-2.6.32-358.2.1.el6.i686.img -rw-r--r--. 1 root root 15450647 Mar 13 17:11 /boot/initramfs-2.6.32-358.2.1.el6.i686.img.bak
- This may not work, because there may need to be some other things
loaded that are not, like the disc controller's kernel module driver, etc. What I think is going on is either something has been removed from this kernel that existed before ... OR ... something is being mis-detected with this kernel on your machine.
Unfortunately, when rebooting into kernel 358.2.1 I get the same result as before.
Thanks for taking the time to look into this. Is it an upstream bug?
On 03/14/2013 10:33 AM, Liam O'Toole wrote:
On 2013-03-14, Johnny Hughes johnny@centos.org wrote:
(...)
Maybe ... try this (everything done as root):
Boot on a kernel that works and do this:
- Backup you current initrd:
cp -a /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img.bak
OK.
- Go to this directory:
cd /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/md/
For me the corresponding directory is /lib/modules/2.6.32-358.2.1.el6.i686/kernel/drivers/md.
- Figure out the md modules loaded in the old kernel:
lsmod | grep dm_
in my case, that output would be this:
[root@localhost md]# lsmod | grep dm_ dm_round_robin 2525 0 dm_multipath 17756 1 dm_round_robin dm_mirror 14133 0 dm_region_hash 12085 1 dm_mirror dm_log 9930 2 dm_mirror,dm_region_hash dm_mod 82839 12 dm_multipath,dm_mirror,dm_log
(note, dm-mod and dm_mod are the same thing)
In my case I have:
# lsmod | grep dm_ dm_mirror 11678 0 dm_region_hash 9609 1 dm_mirror dm_log 8322 2 dm_mirror,dm_region_hash dm_mod 66925 8 dm_mirror,dm_log
- Do an file list and make sure all the modules you need to include
(in my case the 6 in column 1):
ls
Note: make sure all the modules are listed ad you see the file names (should be for me: dm-round-robin.ko, dm-multipath.ko, dm-mirror.ko, dm-region-hash.ko, dm-log.ko, dm-mod.ko)
Yes, all are present:
# ls dm*.ko dm-bufio.ko dm-log-userspace.ko dm-queue-length.ko dm-service-time.ko dm-crypt.ko dm-memcache.ko dm-raid45.ko dm-snapshot.ko dm-delay.ko dm-mirror.ko dm-raid.ko dm-thin-pool.ko dm-flakey.ko dm-mod.ko dm-region-hash.ko dm-zero.ko dm-log.ko dm-multipath.ko dm-round-robin.ko
- Create a new initrd with all the relevant md modules preloaded (in
my case, this command line ... preload only the modules you need from your list .. again, have to do this as root):
mkinitrd -f --preload=3Ddm_round_robin --preload=3Ddm_multipath --preload=3Ddm_mirror --preload=3Ddm_region_hash --preload=3Ddm_log=20 --preload=3Ddm_mod /boot/initramfs-2.6.32-358.2.1.el6.x86_64.img 2.6.32-358.2.1.el6.x86_64
Note: The above mkinitrd command (and all the other commands) should be entered all on one line, I am sure it will wrap when posted.
(Indeed it did wrap.) The command I used was
mkinitrd -f --preload=dm_mirror --preload=dm_region_hash --preload=dm_log --preload=dm_mod /boot/initramfs-2.6.32-358.2.1.el6.i686.img 2.6.32-358.2.1.el6.i686
That produced a file of similar size to the original:
# ls -l /boot/initramfs-2.6.32-358.2.1.el6.i686.img* -rw-r--r--. 1 root root 15450686 Mar 14 15:13 /boot/initramfs-2.6.32-358.2.1.el6.i686.img -rw-r--r--. 1 root root 15450647 Mar 13 17:11 /boot/initramfs-2.6.32-358.2.1.el6.i686.img.bak
- This may not work, because there may need to be some other things
loaded that are not, like the disc controller's kernel module driver, etc. What I think is going on is either something has been removed from this kernel that existed before ... OR ... something is being mis-detected with this kernel on your machine.
Unfortunately, when rebooting into kernel 358.2.1 I get the same result as before.
Thanks for taking the time to look into this. Is it an upstream bug?
It is actually kind of hard to tell where the bug lies ... it is possible that somehow our kernel or other tools are causing some problem, but I would think it is more likely that some driver is not being detected and loaded. If it is in relation to dm-mod, then I would suspect that the driver is for the chipset's drive controller.
If you can figure out which driver that is and make it preload, you might be able to boot ... then we can figure out why it is not detected.
Hello all, I thought some of the LAMP stacks at Bitnami would be great for getting it all setup in Centos. Making sure everything is in the right place and referenced correctly. I'm curious, though, as Centos comes with Apache already and it's running on my system. So, I wonder what these installers do - ignore installing apache, when they discover it is already installed? Make it use a different port? What would be nice would be to put certain things on different domains. That goes back to my previous question about getting the vhost.conf to work and to get my system to use virtual hosts. ...and if you see other lamp relate stacks that look interesting, it would be nice if they could handle the situation where several components are already installed and running and just skip those components when installing... Is that possible? Thanks, Bruce
_______________________________________________________ Bruce Whealton - Web Design/Development/Programming Future Wave Web Development: http://futurewaveonline.com Developing for the Desktop as well as for Mobile Devices - Smartphones/Tablets Call 919-636-5809 _______________________________________________________
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Mar 14, 2013 at 1:42 PM, Bruce Whealton bruce@futurewaveonline.com wrote:
Hello all, I thought some of the LAMP stacks at Bitnami would be great for getting it all setup in Centos. Making sure everything is in the right place and referenced correctly. I'm curious, though, as Centos comes with Apache already and it's running on my system. So, I wonder what these installers do - ignore installing apache, when they discover it is already installed? Make it use a different port? What would be nice would be to put certain things on different domains. That goes back to my previous question about getting the vhost.conf to work and to get my system to use virtual hosts. ...and if you see other lamp relate stacks that look interesting, it would be nice if they could handle the situation where several components are already installed and running and just skip those components when installing... Is that possible? Thanks, Bruce
Your server has probably got all the components of a LAMP stack on it. If it hasn't it is a simple matter of installing them using yum. You would learn a lot by doing it that way. yum will put stuff in the correct locations.
If you are sure that you want to use a pre-packed LAMP stack, then I guess that they must use different ports. I've never used one. I suspect that you will have issues down the track, eg when you need to upgrade either the system or the LAMP stack.
One option is to find an appliance ISO and use that rather than try to install a LAMP stack on top of an existing system.
Cheers,
Cliff
Your server has probably got all the components of a LAMP stack on it. If it hasn't it is a simple matter of installing them using yum. You would
learn a lot by doing it that way. yum will put stuff in the correct locations.
If you are sure that you want to use a pre-packed LAMP stack, then I guess
that they must use different ports. I've never used one. I suspect that you will have issues >down the track, eg when you need to upgrade either the system or the LAMP stack.
One option is to find an appliance ISO and use that rather than try to
install a LAMP stack on top of an existing system.
I suppose you are correct. The real problem I was having was getting domain1.com to point to one location and domain2.com to point to another and to serve php files from both. Previously, I had problems with this, especially frustrating was when php didn't work. Didn't work meaning it wasn't being processed on the server. With my latest install that does work now. It was soooo frustrating. Nothing out there seemed to offer a solution and the log files were unhelpful. These packaged lamp stacks do not resolve the issue of running virtual domains, such as domain1.com and domain2.com. As noted in a prior email, when I added a vhost.conf file, the server would not restart. Thanks, Bruce
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Bruce Whealton wrote: <snip>
One option is to find an appliance ISO and use that rather than try to
install a LAMP stack on top of an existing system.
I suppose you are correct. The real problem I was having was getting domain1.com to point to one location and domain2.com to point to another and to serve php files from both. Previously, I had problems with this, especially frustrating was when php didn't work. Didn't work meaning it wasn't being processed on the server. With my latest install that does work now. It was soooo frustrating. Nothing out there seemed to offer a solution and the log files were unhelpful. These packaged lamp stacks do not resolve the issue of running virtual domains, such as domain1.com and domain2.com. As noted in a prior email, when I added a vhost.conf file, the server would not restart.
You should note that current practice is to touch /etc/httpd/conf as *little* as possible. It includes /etc/httpd/conf.d, and in there, you put your files. What most people do is one for each domain.
mark
On Fri, Mar 15, 2013 at 6:53 AM, Bruce Whealton bruce@futurewaveonline.com wrote:
Your server has probably got all the components of a LAMP stack on it. If it hasn't it is a simple matter of installing them using yum. You would
learn a lot by doing it that way. yum will put stuff in the correct locations.
If you are sure that you want to use a pre-packed LAMP stack, then I guess
that they must use different ports. I've never used one. I suspect that you will have issues >down the track, eg when you need to upgrade either the system or the LAMP stack.
One option is to find an appliance ISO and use that rather than try to
install a LAMP stack on top of an existing system.
I suppose you are correct. The real problem I was having was getting domain1.com to point to one location and domain2.com to point to another and to serve php files from both. Previously, I had problems with this, especially frustrating was when php didn't work. Didn't work meaning it wasn't being processed on the server. With my latest install that does work now. It was soooo frustrating. Nothing out there seemed to offer a solution and the log files were unhelpful. These packaged lamp stacks do not resolve the issue of running virtual domains, such as domain1.com and domain2.com. As noted in a prior email, when I added a vhost.conf file, the server would not restart. Thanks,
I suggest that solving the issues that you get would be ultimately more useful than looking for a solution that works out of the box.
I suggest that you look at the documentation for Apache virtual hosts.
Cheers,
Cliff
On 03/12/2013 05:08 PM, Emmett Culley wrote:
On 03/12/2013 04:23 PM, lists-centos wrote:
------------ Original Message ------------
Date: Tuesday, March 12, 2013 04:05:28 PM -0700 From: Emmett Culley emmett@webengineer.com To: centos@centos.org Cc: Subject: Re: [CentOS] Kernel panic after update to 6.4
On 03/12/2013 01:48 PM, Akemi Yagi wrote:
On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley emmett@webengineer.com wrote:
After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to update the host as well. And it failed to boot.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is not out yet. Where did you get this one from ??? Did you build it yourself?
I figured out that in both failure cases the "yum update" was never completed as I had to run yum-complete-transaction on both. And doing that and re-installing the 358.0.1 had the same boot failures.
Yesterday I did another update which installed the 358.2.1 kernel, which booted. So I guess I'll attempt to update the host machine.
I don't know what happened, but it seems to be resolved.
Emmett
On 03/14/2013 08:03 AM, Emmett Culley wrote:
On 03/12/2013 05:08 PM, Emmett Culley wrote:
On 03/12/2013 04:23 PM, lists-centos wrote:
------------ Original Message ------------
Date: Tuesday, March 12, 2013 04:05:28 PM -0700 From: Emmett Culley emmett@webengineer.com To: centos@centos.org Cc: Subject: Re: [CentOS] Kernel panic after update to 6.4
On 03/12/2013 01:48 PM, Akemi Yagi wrote:
On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley emmett@webengineer.com wrote:
After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to update the host as well. And it failed to boot.
Kernel panic - Not syncing: Attempted to kill init! Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is not out yet. Where did you get this one from ??? Did you build it yourself?
I figured out that in both failure cases the "yum update" was never completed as I had to run yum-complete-transaction on both. And doing that and re-installing the 358.0.1 had the same boot failures.
Yesterday I did another update which installed the 358.2.1 kernel, which booted. So I guess I'll attempt to update the host machine.
I don't know what happened, but it seems to be resolved.
Emmett
Yesterday I upgraded all of the guests (4) and the host to the "358.2.1" kernel. All of the VMs restarted fine, but the host has the same boot failure.
But I have some new information that might make a difference.
First: When I first saw this issue on two machines, I had updated the machines to 6.4 while logged via VNC. Since both of the failures also had incomplete updates and required me to run yum-complete-transaction, I assumed that those yum update session failures were the reason for the boot failure. Because I assume the update caused the vncserver to reset, interrupting the yum update session.
So this time I ran the updates via ssh. All went well, all updates completed, but the host fails to boot on the "358.2.1" kernel.
Here is the new information. When the host boots on the previous "good" kernel I see the simplified plymouth trail (the tri-color tape that runs along the bottom of the screen during boot). But when it boots from the "bad" kernels I see the "fancy" centos splash, with the spinning circle under the CentOS logo.
In all cases, the VM guests all boot with the simplified splash. So I suppose that means the the new kernel installation is incorrectly detecting my video hardware.
Can anybody suggest some changes I can make to the kernel parameters that could mitigate that mid-detection?
Emmett
-
Bruce Whealton -
Cliff Pratt -
Emmett Culley -
Johnny Hughes -
Liam O'Toole -
m.roth＠5-cent.us