On Sun, 24 Mar 2002, eric nelson wrote: > First, something about mount program didn't pass correct address, then > RPC: sendmsg returned error 101 > nfs: RPC call returned error 101 > .... over and over > > There are so many errors, that I can't scroll back. I'll need to redo > the kernel w/ the option Peter Jay Salzman mentioned. > > I'm not doing the kind of mount straight from the bios, but I want to > learn how to do that one, later. I have a boot floppy which loads a > kernel, then gets an address from dhcp server, then mounts on nfs. > I'm sure the problem is in init scripts, or fstab or something. > > It's good to know someone is doing this, it's a great approach.
First, check out the netboot howto/docs. Second, make sure the server is exporting the filesystems in question on a non-netbooting box/session with normal # mount -t nfs host.name:/export/path /local/mount/point Why? You can make sure the server's /etc/hosts.[allow||deny] is set up in such a way to allow portmap and nfs stuff from a client's IP address to work. If that works, then try to test the next step. Start up a netbootable kernel with loadlin or lilo (special entry on a disk-booting system) to tell it to netboot instead of use the local disk. Certainly, it will still grab a kernel from the local disk but shyould do the rest over the network like it was diskless. Checkout /usr/src/linux/Documentation/nfsroot.txt You should be able to add an entry to lilo.conf (or at the lilo prompt) like: (Use IP addresses to eliminate DNS as yet another piece to work out.) LILO: Boot: mykernel root=/dev/nfs nfsroot=IP.Addr.Of.Srvr:/path/to/root/export ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>* *= See the above mentioned linux kernel doc for this line. It is a good idea to test with a hand-enetered IP address for client and server as well as all other info to eliminate bootp/dhcp from the list of possible problems. And you could, of course, have added those items into a separate lilo.conf entry to save re-entry of those keystrokes every single time. If that works, then remove the client ip and let everything else be determined except for server ip, next drop server IP and let it all be dynamic, and then try to shift to let the special bootp/dhcp response include the nfsroot. (At this point, if all else works, then you would only be passing the: root=/dev/nfs ) Next, if you want it to be true network booting (bootp/dhcp then tftp of kernel, and finally boting kernel get nfsroot and goes) then you will likely need some sort of modification to your final compiled kernel that would be dl via tftp (a boot strapper of sorts.) I use the netboot stuff with programmed EPROMS dropped into the ethernet cards. ( http://sourceforge.net/projects/netboot ) I have found testing each part, one-at-a-time save troubleshooting and leads to a steady advance to solutions. Of course, there is a great sense of accomplishment when you take a big project with lots of pieces, throw it all together and note that it all works the first time too. ]:> -ME -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
