Debian replicator boot disk problem 22

If i understand it right, you posted a syslog entry

Dec 30 18:59:46 localhost rpc.mountd: refused mount request from 192.168.0.13 forexport-miniroot (-): no export entry

This only makes sense to me if the localhost is the *server* and 192.168.0.13 is the *client*.

How could the server write this in its syslog, unless the client really sent a request to the server? Why would the *server* refuse the request just because the *client* does not detect its hd, brush it teeth, or sing negro spirituals?

There is still a potential for myself being the one who misunderstands, (shame that I'm so sarcastic then) but you have failed give us a clear map of the landscape of events. Now I have one reference point: There is a computer involved that has IP address 192.168.0.13, and that computer has sent an NFS mount request to another computer - about which I don't know the least, except that it has a syslog, and runs an rpc.mount daemon. It would be nice if you had described things in such a manner that we could refer to the computers involved using labels that you had introduced. Why don't you say

"I have three computers A,B, and C, with IP addresses 192.168.0.{10,12,13} respectively, and I am using A as an NFS server, with the following exports file:

exports 192.168.0.*(rw, norootsquash)

The directoryexports contains two subdirectories:

which are both on the same parbreastion asexports. The underlying file system is ext3.

B has the following entry inetc-fstab:

A:-exports-mypictureshome-ego-photos nfs user,bg,rw,soft 0 0

and that seems to work just fine, I have browsed the directories and even viewed the pictures on the screen.

C is a diskless station, and mounts its root file system from A. This is how I boot C... This is the fstab entry..."

Agreed. It would be great. Unfortunately I can only say: I'm 100% sure that I, in your place, would have wanted to investigate why the server refuses the mount request. I don't know what would be the outcome of that investigation. Should I come over to your place and do it?

Problems with the size and the supported stuff? You mean... Oh you need to keep the kernel image small, and have trouble determining what to include and what not. (Why do you need to keep it so small? No, let's come back to the kernel later, if it turns out to be required.)

OK. We can come back to the kernel as soon as we have evidence that it needs revision. (But why do you need ext3 if you have no harddisk... Oh, Enrique! Stop it. Leave the kernel alone for now. :) )

Oh, but this is new information. This may warrant an examination of the kernel configuration, but it may also just mean that the nfs mount is the root file system, and the kernel panics if it cannot mount the a root file system. It needs a root file system, because it wants to run a program called "init" in the root file system. If it can't run "init" it's not much else it can do!

Of course one could imagine a broken kernel on the client side sending improperly formatted mount requests, just because it is so broken. But notice that this is a kind of imprecise thinking, like "Oh, so the car has run out of gas? I guess the plugs are bad too. I have heard that cars that don't run often have bad plugs."

I don't find it likely that you would modify the c code of the kernel. If you have just made your selections in the kernel configurator, you should either have a good NFS client support or no NFS client support at all, and the crash should be due to something external to the NFS support itself.

I would definitely look into the actual configuration data before taking on a rather difficult kernel debugging task.

You don't tell what directory the other linux mounts. Is it the sameexports-miniroot?

And watch your language: "Connection refused" has a rather specific meaning. You are *not* seeing refused connections!

-Enrique