On 11/17/2006 11:04, Chacko Cherackal wrote: > If this doesn't work I'm going to try Jason's suggestion of forcing > recognition using mknod. I'm holding off to use that as a last resort > because it seems like something I could use to muck things up even further. Terminology is a bit off here... All mknod does is create files[1] there is no "recognizing" or anything like that going on. UDEV and similar are the ones that do auto-recognition. As you're finding out, this type of modern functionality is not very long in the tooth. This manual device creation also used to be handled by a script (even an executable in some cases) called MAKEDEV. I believe that MAKEDEV was a redhat invention, eons ago. One problem (besides extreme pain in dealing with dynamic hotpluggable hardware) with manual device node creation is that the /dev directory was typically cluttered with hundreds of nodes that pointed to hardware that didn't even exist in the system. The worst offender was probably the dozens and dozens of serial ports, left from the days of many serial terminals operating off of one server. With dynamic detection and creation, what you see is what you have, unless it doesn't work, which leads to your situation.[2] If you make a mistake using mknod, you won't have screwed anything up, and can just delete the files you have created. I think, but am not sure, that you may be able to create these device files not just in /dev, but anywhere you want "just in case" (e.g. create /root/dev/sda1 etc...) Then it's just a matter of using your software raid tools to tie together those device files that you created ~Jason -- [1] OK OK they're device pointers and not *really* files in the sense that they contain data. They are however, just files as far as the filesystem is concerned (e.g. you can ls/rm/cat/echo "foo" > to/from them just like any other file). NOTE: doing some of those things NOT necessarily recommended! [2] Trivia: Windows has had this dynamic device creation and coresponding device nodes for quite some time. If you dig into the kernel API, you can find such things as \Device\Harddisk1 and so on. If you look at OpenVMS (red-headed stepfather to NT), you will see these same names... As is so painfully typical under windows, the user can not directly interact with these special files, as one can under Linux.
More information about the ECLUG mailing list