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:
January 6: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Mar 26 19:45

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



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.

-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



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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.