l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2002 Mar 26 14:03

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] need to debug boot crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] need to debug boot crash



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
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!