After updating to udev-146-r2 from r1 an automount partition fails to mount during boot because device is missing. Console confirmation /dev/hda25 is not there, though /dev/hda24 is present. reverting to r1 fixes the problem. Reproducible: Always Steps to Reproduce: 1. create partition table on ide with 25 partitions 2. emerge udev-146-r2 ; reboot 3. attempt mount /dev/hda25 .... 4. ls /dev/hda25 5. ls /dev/hda24 Actual Results: /dev/hda24 is present /dev/hda25 is not Expected Results: /devhda25
As I already mentioned, current git doesn't create any dev/hd* nodes in default rules (neither for cdroms nor for hard drives).
#1: what is the implication of your comment? Does that mean udev is abandoning the kernel ide support and my system will no longer boot or that there is a new mechanism? Don't be too hasty to remove /dev/hd* , this box has decided not to create /dev/cdrom, I need /dev/hdc to access the hardware. Despite all the magic, ephemeral device names I think as long as there are ide plugs on motherboards there should be corresponding device nodes. The rest is convenience trickery. This convenience is relative. It seems each time I update udev (which I avoid doing too often) I have to reconfigure some rules since there have been incompatible changes and no respect for backwards compatibility with previous udev stanza. For the current bug udev does create devices but it seems some arbitrary limit of 25 was coded in when moving from r1 to r2 here. That should be pretty easy to find and rectify. I saw a similar bug on Arch linux where a user had 40 . It seemed to be the same issue. Isn't there a spec for this? thx
On a semi-related note: it seems that in recent kernels there is an option to go around SCSI minor 15 limit, though marked as a risky one (however it seems, that in most cases it should just work). It's DEBUG_BLOCK_EXT_DEVT.
CONFIG_IDE and /dev/hd* shouldn't be used anymore. If any of this is still relavent with the new (P)ATA stack, let us know.
