On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote: > You can change the 'rw' in /etc/exports all you want, but it > still wont' make the workstation mount it in read-write mode. > > That is controlled by the mount command inside the /linuxrc script > that is in the initrd.
*** Oh yes, sorry my mistake (differences with V2 & V3). Then you would need both: change the NFS export on the server and change the initrd. I dont think changing the current initrd should be that difficult. You would uncompress it (gunzip), mount it via loopback device, edit /linuxrc, compress it (gzip) > > Jim McQuillan > [EMAIL PROTECTED] > > > On Fri, 12 Jul 2002, John_Cuzzola wrote: > > > > > > > *** Here something that might help you track down where the problem > > is. On the server Change to the root directory of the ltsp client. (For > > LTSP V2 its /tftpboot/lts/ltsroot for V3 its in /opt). Now look for any > > core (or core.xxxx) files > > > > find -name core* > > > > and delete them. > > > > Now edit /etc/exports and export the client root read/write (for example): > > > > /tftpboot/lts/ltsroot 192.168.0.0/255.255.255.0(rw,no_root_squash) > > > > > > Make sure you restart NFS. > > > > Ok now boot your clients until one of them dies. The theory is a user-land > > program that segfaults will write a core file (dump it's core) to > > the nfs share that is now read/write. After that > > happens go back to the server search for core files within the clients > > root directory as before. If you find one then issue this command: > > > > gdb -c core.xxx > > > > This will tell you which program segfaulted. > > > > > > Good luck :) > > > > > > > > > > > > > > On Fri, 12 Jul 2002 [EMAIL PROTECTED] wrote: > > > > > John, > > > > > > I've missed the first part of the problem. Which binary are > > > you trying to run that results in the segfault ? > > > > > > Jim McQuillan > > > [EMAIL PROTECTED] > > > > > > > > > On Fri, 12 Jul 2002, John Karns wrote: > > > > > > > On Tue, 9 Jul 2002, John Karns said: > > > > > > > > > That's the part I wasn't sure about. Actually, I was thinking that the DC > > > > > perhaps was getting the dhclient binary which resides on the server and > > > > > executing it from within the LTSP environment, which uses a different set > > > > > of libraries than those which the binary was compiled under. I wasn't > > > > > questioning the internal consistencies of LTSP. > > > > > > > > > > It does indeed seem to be hardware related, but as far as I can tell, the > > > > > mobo (ASUS P5A) is to blame. I've swapped the entire client machine (with > > > > > the same mobo) as well as the hub and patch cables with the same problem. > > > > > Due to the intermittent nature it's difficult to say with real certainty, > > > > > but the problem appears to occur only when the P5A has an AGP card > > > > > installed. I tried two different AGP cards - a generic card employing a > > > > > Trident Blade3D chip, and an ATI Rage Pro. The problem disappears when I > > > > > replace the AGP card with an ISA video card. > > > > > > > > > > I am declaring the test a success though, because I won't be using the > > > > > ASUS P5A machines as clients for the main part of the project. Although > > > > > it's still disappointing because I do have a few of the P5A which I was > > > > > thinking I could use as DC's later on. > > > > > > > > Well I'm still grappling with this problem here. I've swapped absolutely > > > > everything, including making the former server machine the DC and > > > > vice-versa with the former client. Still getting a segfault. I don't > > > > think that the ASUS P5A mobo was / is at fault. > > > > > > > > Since the beginning, the 1st one or two boots are successful - sometimes > > > > up to 5 or so, other times it segfaults on the 2nd boot. I've tried > > > > both kernels 2.4.9 and 2.4.18 from the LTSP kernel tgz. > > > > > > > > I'm thinking that the problem lies on the server side, as once I had my > > > > laptop also booting from floppy as a DC to have 2 DC's - and after the > > > > problem ocurred, neither DC was able to boot due a segfault. > > > > > > > > I'm running out of ideas. Any hints on how to debug this? I've DL'd a > > > > busybox tar file and had the idea to compile it myself - that may be my > > > > next step. I'll have another look through the LTSP docs to see if there's > > > > info on building from BB source - any tips regarding that much > > > > appreciated. > > > > > > > > One other point is that the machine I'm testing as a client has an > > > > integrated Trident Blade3D chip. When there is a successful boot of the > > > > DC with runlevel 5, the X window manager fails to start and the screen > > > > shows the large X on the monochrome "checkered" background. When I had > > > > the client and server machines reversed, the Blade3D AGP card in the ASUS > > > > worked fine after successful boots. > > > > > > > > Thanks > > > > > > > > ---------------------------------------------------------------- > > > > John Karns [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Gadgets, caffeine, t-shirts, fun stuff. > > > > http://thinkgeek.com/sf > > > > _____________________________________________________________________ > > > > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > > > > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > > > > For additional LTSP help, try #ltsp channel on irc.openprojects.net > > > > > > > > > > > > > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
