Hello!
I just wanted to report that I finally found a way to
generate more than 256 device nodes for a major device:
Making a dist-upgrade to Debian Etch ("testing")!To avoid any bad sideeffects that could postpone my project any further all installations have been made inside a VMware Server environment. These are the steps that have been done: 1. Installation of a "pure-as-possible" Debian Sarge. No X, no compiler - only what is necessary to boot a small Linux. After the installation all possible updates have been done. Tested if the phenomenon happens: mknod testnode1 c 200 255 mknod testnode2 c 200 256 This generates the following two files testnode1 200 255 testnode2 201 0 Conclusion: the effect occurs. 2. Modifying /etc/apt/sources.conf: changed all appearences of "stable" to "testing". Made an "apt-get update" to freshen the package cache. 3. Finally did a "apt-get dist-upgrade". This found about 190 packages that needed to be upgraded. Confirmed every question with its default option. After all was updated the machine was rebooted. Kernel was still the old kernel 2.6.8-2. Now repeated the test: mknod testnode1 c 200 255 mknod testnode2 c 200 256 generates the following two files testnode1 200 255 testnode2 201 256 Therefore it is assumed that upgrading a Debian Sarge to Etch fixes the device file minor number limitation! => Problem is solved (but not yet understood) My question now is this: Does anybody out there have a glimpse of a clue about the real cause of this behaviour? I bet that it has something to do with libc6 - but I am not sure as I have not found a proof for this yet. (Even the libc6 changelogs are unhelpful in this case.) So far I think that this can solve the problem for our customer. Thank you's go out to everyone who helped in this case!!! Best regards, Stefan Sperling N.A.T. GmbH Software Developer / Net Admin --To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
