I'm having problems with an upgraded fedora system. Recently Amazon added EBS based images and I decided to give it a try. I launched a basic FC8 instance and upgraded it with yum. First up to FC10 and after that up to FC12.

Well I'm missing /dev/random on the FC12 instance now and there're some other obscure things. For example: /dev/null has 600 permissions and /dev/urandom is not a block device. /dev/random is absolutely gone :)

I read here http://markus.revti.com/2007/12/creating-devrandom/ , how to "fix" the above problems, however on every start of the system everything is the same. I'm planning to add the fixes to /etc/rc.local . Do you think this is a good solution/workaround?

Does anyone know where the problem exactly is?

Thank you for any advices and shared knowledge,


p.s. The instance is running this kernel:


I believe they are created by udev. Comparing the contents of your /etc/udev directory to a working system or looking at /var/log/udev might give you some insight.

| improve this answer | |

You can't really upgrade an ec2 image like that. Since the kernel is provided by Amazon, you have to make sure to boot your instance with the kernel that matches, or odd behavior (like you described) will happen.

Pretty much the only way to "upgrade" a system that requires kernel changes is to either build a new image from scratch or find an existing AMI with the OS rev that you want.

| improve this answer | |

You can run:

/sbin/MAKEDEV std

to have those device files (and a few others) created.

| improve this answer | |
  • Thank you. Where do you think is the best place to add this command to be executed on system start? – Stan Bright Dec 7 '09 at 14:27
  • You can add that command to the /etc/init.d/udev script, or create your own script and the symlinks in the right /etc/rc.? directories. – Gonzalo Dec 18 '09 at 22:17

Most modern Linux distributions use udev to dynamically populate the contents of /dev.

Typically your root FS only needs static entries for /dev/console and /dev/null in order to bootstrap. Once booted, a tmpfs mount overlays /dev, in order to provide the full compliment of device nodes.

Some diagnosis steps..

  • Determine whether your kernel supports udev with: dmesg | grep udev
  • Check whether the daemon is actually running with: ps ax | grep udevd
  • Check whether udev is mounted with: grep udev /proc/mounts

You can and should check the contents of /etc/udev as per Kyle's answer. Although udev should function at a basic level without any rules at all, so it's less likely to be the cause.

Don't go creating all of the nodes manually because it will come back to bite you at a later date.

| improve this answer | |

I found where my problem is:


In fact when I've upgraded to a newer Udev it uses signalfd(2) , which is not available in my EC2 kernel.

I hope this info will help to someone else.


| improve this answer | |

What Kyle said. The Fedora wiki has an article: Upgrading Fedora using yum -- in particular, I'd check for .rpmsave files in /etc as described in the "Clean Stuff" section. Fixing the problem is always a better idea than trying to fix the symptoms and likely missing something important.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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