Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Everytime I start a new RHEL instance, I like to perform a yum update to start with the most up-to-date system. However, everytime I try to reboot the instance after that, the instance never goes live anymore.

I troubleshooted the root cause to be the kernel update, here are the minimum steps to reproduce the problem:

  1. Launch a new RHEL 6.1 instance
  2. Connect, then run:
    1. yum update kernel*
    2. reboot

The system stays down. The system log from the EC2 management console doesn't help much:

Please stand by while rebooting the system...
md: stopping all md devices.
xenbus_dev_shutdown: device/console/0: Initialising != Connected, skipping
Restarting system.

No mention of a kernel panic, startup problem, etc. Just stuck there.

From what I can read around, it looks like you can't use the default kernels with an EC2 instance. If that is true, how can I avoid to accidentally update the kernel with yum, and thus killing my instance, when performing a generic yum update?

share|improve this question
up vote 4 down vote accepted

just edit the file: /etc/yum.conf and add an entry in it like this:

exclude = kernel*

After it, yum will exclude all packages, having kernel in its starting name.

You can read more details in this url:

Regarding the issue that you are unable to upgrade kernel, then you are right that you CANNOT upgrade the kernel like you upgrade in normal PC. Amazon EC2 uses customized settings in case of kernel setup, for detailed info, please follow this URL that how to perform kernel upgrade on EC2 instance:

share|improve this answer

It looks like you've encountered a bug in the version of the kernel included in RHEL. There was a thread about this problem on the Xen development email list last year:

You should probably try rebooting your instance via the EC2 console or command line utilities.

Regarding the issue that you are unable to upgrade the kernel: that is no longer the case for modern Amazon Machine Images (AMIs). Newer AMIs like the RHEL 6 AMI boot with PV-GRUB, which allows you to upgrade the kernel like you would on any other server.

For more information about PV-GRUB, refer to the EC2 documentation here:

share|improve this answer
Thanks, so that definitely looks like a bug. I'm just surprised that being so easy to reproduce, it isn't already fixed. By the way, I also tried to reboot via the EC2 console, and didn't have more luck with that solution. – Benjamin Dec 6 '11 at 10:31

the problem is the name of the block device changes from /dev/xvda to /dev/xvde you can change the menu.lst to point to /dev/xvde1 and fstab to mount xvde 1 2 3 or label the drives and poit to the labels

i use labels and the problem is fixed.

share|improve this answer

I was really blocked by this issue but it seems I have got arround it now. The kernel hint doesn't seem to be relevant now, but I found that removing /var/lib/dhcp-client/* files is really helping.

Taken directly by some tech-trainers at AWSomeday, the 2 checks done by Amazon in the monitoring are :

  1. CPU is not IDLE
  2. Network interface is present

So first thing to do is to check at what monitoring step you are going to. If 1/2 are OK it might be a good chance that you have a DHCP problem. And so above solution might work for you.

share|improve this answer

It seems that the new releases made by Amazon use LABELS but this doesn't really fix the issue. The issue appears when you start mounting another instance volume in order to do some recovery on it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.