ME wrote: > 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 )
Thanks for the major breakdown of the project. It's going to take me a little while to read these docs., and go through the whole process, but we want to use this for two things: 1) testing an os we are putting together. we can work on the os on a host machine, then boot it on the target to test, so the target is a simple machine and the host has full development enviroment. 2) we are developing a linux based product, which will net boot as an option, so we need to understand the whole process very well. I have read that people use this technique to boot multiple diskless workstations. Is that what you use it for? > > > 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 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
