[vox-tech] need to debug boot crash

eric nelson vox-tech@lists.lugod.org
Tue, 26 Mar 2002 19:45:33 -0800


ME wrote:

> Sorry for the delay, I am going through my mail now...
>
> On Mon, 25 Mar 2002, eric nelson wrote:
> > 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.
>
> This is a good idea. I'll also suggest copying the tree to a backup before
> exporting it in testing as rw. Why? If you test station boots, but does
> not shutdown, files will be left behind in /var/lock and /tmp that may
> cause problems with the next booting station - especially if the
> production system's root export is a ro export.
>
> Also, avoid using tar to creat backups of the exporte system root. It has
> a history of bugs. I used it for the longest time, and was a die-hard user
> of it, but finally gave up on it for archived system roots like netbooting
> system roots.
>
> Instead of tar, try " cp -aR " the "a" is for archive (permissions and
> special flags) and the capitail "R" does recursive like "r" but deals with
> device special files as you would most likely want (no tries to read the
> contents of the device - yeeech)
>
> Yes it uses up more space than a tarball, and is not compressed, *but* it
> seems to work with all of the files, and is short/easy to remember. (Dont
> use " cp -ar " as it will probably try to read the contents of devices
> like /dev/sda and make copies of the contents instead of the c/b/f special
> devices.)
>
> (Had problems with tar and some dev special files, some permissions not
> being copied as they should and certain major numbers that were "too
> high" not being copied and.. and... and... Yes, yes, i know about all the
> special flags for tar, and had a command line tar command that was 3 lines
> long at one time to almost get things to work as well as " cp -aR ".)
>
> > 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.
>
> Though it is not *exactly* the same thing, I reverse engineered Apple's
> Propritary NetBoot-ing protocol and published papers on how it works. You
> may be able to grab some useful information on the pages I created for
> this "how-to" as it is very close the the "standard" *NIX diskless client
> system (using modified DHCP with vendor extentions instead of the standard
> method and AFP/IP instead of NFS.)
>
> Others out there have written much better pages on Linux and diskless
> client booting.
>
> http://mike.passwall.com/macnc/
>
> > I have read that people use this technique to boot multiple diskless
> > workstations.  Is that what you use it for?
>
> Yep, about 80 or more diskless client workstations (no local HD, no local
> floppy disk, no moving parts except the fan on the CPU and power
> supply.) The root is mounted as a ro NFS root, and is exported from the
> server as such (for better security.) Having diskless client do their work
> from a root filesystem that is readonly is a bit tricky, but possible. (We
> have use the 2.0.x and 2.2.x kernels, but are now using the 2.4.x kernels
> for this.)
>
> Have used it home on a private network with firewall rules and did some
> with roots being (rw) but dont suggest this on more open networks with
> NFS. Also, no two machine should share the same system roots (when /var,
> /tmp and others) are part of that root when the roots are mounted as (rw).
>
> Also, based on som complaints from another user doing netbooting, there
> may be problems with having the server use reiserfs or ext3 with nfs
> exports as root for the clients. (Not experienced this as I use ext2 for
> this still. Also, no references for this other than, "some guy said this
> was a problem.")
>
> Done many kind sof netbooting including use of a BSD based system on an
> Sun 3/60 with XTerm support for remot processing and local display.
>
> Wayyyy back when, I wanted to do netbooting of windows too, but have heard
> netbooted windows stability rating makes normal desktop windows look like
> a happy thing as interruptions to networking cause delays for file access
> of the OS that are unbearable to the OS.
>
> I am far from a netbooting guru, but I may be able to answer some of the
> simple questions if you should wish to ask.
>

Well, my queue is filling up w/ all this information, it's going to take some
time to assimilate it all.

But, I do have some more questions.

First, our bios mentions something about netboot.  This must be something
pretty generic, that works w/ various OS's.  So, doing a netboot from the
bios, is this the same type of thing?

Second, I looked at the sourceforge netboot project.  It looks like quality
stuff, but again, I need to get some busywork out of the way, then I can dig
into this stuff.

Last, for now, what we really want to do is read a switch from a port, then
either do a normal boot, off the flash disk, or boot into some menu which will
allow either booting into a diagnostic shell which will permit adding new
software, running diagnostics etc., or doing the netboot we have been talking
about,  I guess this is all possible using all this stuff, along w/ lilo, and
some shell scripts, etc.  (I am just asking for affirmation, this is our
plan).

Well, sure appreciate the discussion. ;~)

>
> -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