> indeed that's a possible workaround. well i assume that you are > using a static /dev tree. in that case makedev handles which devices > show up in /dev.
> as one can't populate every debian system with all possible devices, > the maintainer maid a trade-off to cut after 8 discs, which should > not be noticable for the vast majority. *I* didn't make any choice about what kind of /dev tree to use. The installer did. I couldn't find any place to select devfs, and I didn't find any difference between choosing a 2.4 or 2.6 kernel when starting the installer. While I agree that it would be impractical to populate a static /dev tree with all possible devices, it *would* be practical to populate a static /dev tree with all physical partitions used in RAID devices configured from the installer's partitioner. > sure, read the man of MAKEDEV(8) it tells you how to create those > needed nodes. I did try that. However, there's not really an opportunity to create additional device nodes during a from-scratch install. I tried several different ways to do that before the installation of the kernel-image package, but didn't come up with one that worked. (Hence my falling back on the approach of moving the drive for hdi to hda.) Of course none of this is to do with initrd-tools, however: > initrd can't possibly work for non existing device nodes. I'm not suggesting that it should. However, sitting in infinite recursion during an install for over an hour with no indication to the user of either progress or problems is profoundly unhelpful. (I had to spend several days figuring out what was going wrong, and many people would not be capable of debugging this kind of issue.) To me, such behavior does not seem acceptable, and I would argue that it is, in fact, a bug. This particular problem could be detected and handled at several different points in the mkinitrd script. I'm attaching a patch which shows at least two different ways to avoid this long-running infinite recursion. --Ken
mkinitrd.patch
Description: Binary data
