From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041003
Description of problem:
RHEL4b1 includes the IPMI kernel modules. When loaded they register
the character device major 253 (according to /proc/devices), which
can be used by userspace applications to send IPMI commands.
This should be bound to /dev/ipmi0 and/or /dev/ipmidev/0, as it was in
RHEL3u3. On my RHEL4b1 machine there are no nodes for IPMI at all.
Maybe they got lost in the transition to udev?
If I run by hand "mknod /dev/ipmi0 c 253 0" then I can run my IPMI test.
I don't know enough about udev at the moment to work out the right way
to get it auto-added.
I don't know ipmi... according to _my_ /proc/devices ipmidev uses char
according to devices.txt:
240-254 char LOCAL/EXPERIMENTAL USE
240-254 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
used in order to avoid conflicting with future
so please fix the kernel module to provide the device through sysfs...
$ fgrep -ri ipmi /etc/makedev.d
/etc/makedev.d/linux-2.6.x:c $ROOT 10 173 1 1 ipmikcs
Also MAKEDEV does not know about it.
From looking in the 2.6.7 kernel source, it does register_chrdev()
with major number 0, so it's dynamically assigned by the kernel; this
may be why the number has changed.
Looking at the (kernel.org) 2.6.9 source I see this driver calls
devfs_mk_cdev, etc. I don't know what happens to that on systems
without devfs. I'll have a look in a bit.
On closer inspection, it turns out that the devices were not present
in RHEL3 either -- they had been manually created on the machine I was
looking at. So since this is not a regression compared to RHEL3 you
might want to treat this as less serious.
I think it is still a bug though. A proper fix probably requires
changing the module to properly register in sysfs/udev/whatever.
FYI, 2.6.12's ChangeLog contains:
[PATCH] Add sysfs support for the IPMI device interface