| |||||||||||||
Tracking down a "runaway loop"Tracking down a "runaway loop"Posted Jan 7, 2011 19:54 UTC (Fri) by daniel (subscriber, #3181)Parent article: Tracking down a "runaway loop"
"Bickering about where and how to fix the problem before it is fully understood seems counter-productive at best."
Hi Jon,
This problem still exists more than two years out. In all probability the bickering approach would have been more productive.
(Log in to post comments)
Tracking down a "runaway loop" Posted Jun 3, 2011 17:32 UTC (Fri) by cfriedt (guest, #75420) [Link]
Just in case somebody runs into a similar error like the one Vim[1] (& more recently I) ran into
request_module: runaway loop modprobe char-major-0-20481
This is actually the same problem as the missing '/dev/console' but the device files get mangled somehow on the nfs server system.
Note that /dev/console is normally (maj,min) 5,1, but in this case, the kernel is pressed to search for 0,20481 which is notably outside the usual numeric range for device nodes.
I discovered this problem while using VMWare to run a Linux instance with an NFS root hosted from Mac OS X, while Vim discovered this problem doing the same but while running Windows.
It turns out that, if you run 'mknod -m 600 console c 5 1; mknod -m 666 null c 1 3', and then read the result back from within the VMWare instance of Linux, it's identified as follows:
# ls -la console null
The solution: don't use mknod on Mac OS X or cygwin ;-)
In my case I created these critical device nodes on the NFS root from within the VMWare Linux instance with the use of a livecd iso, as a last resort.
In case anyone is interested, after re-creating the 'correct' device nodes using the VMWare Linux instance, the respective files on the nfs root (Mac OS X) show up as follows:
$ ls -la console null
Note: I'm using NFSv2 due to some brokenness with the Mac OS X NFS server implementation.
[1] http://www.mail-archive.com/davinci-linux-open-source@lin...
|
|||||||||||||