On Thu, Jun 05, 2003 at 01:03:17AM +0200, Bernd Walter wrote:
> On Wed, Jun 04, 2003 at 02:21:29PM -0700, jle wrote:
> > on HTTPD: (/etc/fstab)
> > NFSD:/home2 /home nfs rw,bg 0 0
> ed /etc/fstab
> /home2
> s/home/home2/
> w
> q
Don't exactly do this sin
> > [EMAIL PROTECTED]:~ -13:55:06- # cd ~dkdesign
> > -su: cd: /home2/dkdesign: No such file or directory
>
> Not surprising, because you mounted on /home not /home2.
There shouldn't BE a /home2 on HTTPD but I figured out what happened. I
copied /etc/group /etc/passwd /etc/pwd.db and /etc/master.p
On Wed, Jun 04, 2003 at 02:21:29PM -0700, jle wrote:
> I retired my old p200 fbsd 4.4-stable web server and built a newer box for
> it. I used to mount the /home2 dir from my nfs server (fbsd 5.1-current)
> to /home on the webserver and it used to work fine but now it doesn't
> mount /home2 on /ho
I retired my old p200 fbsd 4.4-stable web server and built a newer box for
it. I used to mount the /home2 dir from my nfs server (fbsd 5.1-current)
to /home on the webserver and it used to work fine but now it doesn't
mount /home2 on /home on boot up. I can manually mount it but then it
gets confu
[-current from 04/21 ]
After I upgraded from a current dated approx 04/15 to current from
04/21, my movemail stopped working on NFS mounted partitions (i use
XEmacs and VM for mail). I tested it out and it works fine on local
partitions.
My normal NFS server is a FreeBSD 3.4-stable box. I also
:>
:> I found it. The problem was introduced when we committed the
:> mmap() zero-invalid-areas patch. !...@#$@#$#$%...@%@#%#@ NFS is such
:> a fragile piece of junk!
:
:Why do you say that? :-)
What it come down to is that due to the way m->valid is set, it is possible
for
On Mon, 12 Apr 1999, Matthew Dillon wrote:
> :Probably- but this is sure amusing (not!):
> :
> :Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:
> :
> :
> :
> :cd9660_bmap.o: file not recognized: File format not recognized
> :*** Error code 1
>
> I found it. The
:Probably- but this is sure amusing (not!):
:
:Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:
:
:
:
:cd9660_bmap.o: file not recognized: File format not recognized
:*** Error code 1
I found it. The problem was introduced when we committed the
mmap() zero-inva
Probably- but this is sure amusing (not!):
Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:
cd9660_bmap.o: file not recognized: File format not recognized
*** Error code 1
Stop.
quarm.feral.com > file cd9660_bmap.o
cd9660_bmap.o: MS Windows COFF Unknown CPU
Filesy
Alfred Perlstein writes:
>This is freebsd following the NFS spec, please read the mount_nfs
>man page for the workaround (hint: intr).
In my experience the 'intr' filesystem mount option does not always
work. As an example, I am often unable to abort from a hung 'df' when a
remote NFS server is
On Wed, 31 Mar 1999, Thomas Schuerger wrote:
> Hi!
>
> I'm experiencing serious NFS problems, when
> a remote NFS directory (also on FreeBSD) mounted on my
> machine goes down for whatever reason (e.g. normal
> shutdown). From then on, any processes accessing the mount
Hi!
I'm experiencing serious NFS problems, when
a remote NFS directory (also on FreeBSD) mounted on my
machine goes down for whatever reason (e.g. normal
shutdown). From then on, any processes accessing the mounted
NFS directory (e.g. executing ls or even df) will die and stay
non-removable
:In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current
:(as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those
:circumstances I end up with programs locking due to write problems.
:
:I'm no good a debugging, so if someone could hold my hand through this
:one...
:
In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current
(as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those
circumstances I end up with programs locking due to write problems.
I'm no good a debugging, so if someone could hold my hand through this
one...
Basic
>> This reminds me; do we have a utility to reference wmesg strings back
>> to the code that sets them, a la TAGS? Would this be useful?
> No, and yes respectively.
Okay, I've got an early version written. It's got some fairly
substantial TODO's, and needs a fair bit of cleanup. I would
appreci
On 23 Feb 1999, Joel Ray Holveck wrote:
> >> This reminds me; do we have a utility to reference wmesg strings back
> >> to the code that sets them, a la TAGS? Would this be useful?
> > No, and yes respectively.
>
> I have the scanner mostly written; there is one bug yet to fix (This
> time for s
>> This reminds me; do we have a utility to reference wmesg strings back
>> to the code that sets them, a la TAGS? Would this be useful?
> No, and yes respectively.
I have the scanner mostly written; there is one bug yet to fix (This
time for sure!). Presently, it creates a single file WTAGS whi
On 22 Feb 1999, Joel Ray Holveck wrote:
> >> The program on the client side always freezes (top reports it's
> >> STAT as 'D').
> > You need to pass the 'l' switch to ps and look at the 'wchan' column to
> > see where it's actually stuck.
>
> This reminds me; do we have a utility to reference w
> >> The program on the client side always freezes (top reports it's
> >> STAT as 'D').
> > You need to pass the 'l' switch to ps and look at the 'wchan' column to
> > see where it's actually stuck.
>
> This reminds me; do we have a utility to reference wmesg strings back
> to the code that sets
>> The program on the client side always freezes (top reports it's
>> STAT as 'D').
> You need to pass the 'l' switch to ps and look at the 'wchan' column to
> see where it's actually stuck.
This reminds me; do we have a utility to reference wmesg strings back
to the code that sets them, a la TA
> I update 3-Stable nearly weekly, and have been experiencing the same problem
> for quite a while now. NFS imports, on the client side appear to be losing
> data. When this occurs, I see .nfs78969 files on the server side.
These files exist because they've been deleted but not closed; this is
I update 3-Stable nearly weekly, and have been experiencing the same problem
for quite a while now. NFS imports, on the client side appear to be losing
data. When this occurs, I see .nfs78969 files on the server side. The
program on the client side always freezes (top reports it's STAT as 'D').
>Date: Mon, 1 Feb 1999 14:25:03 +1300
>From: Joe Abley
>Never had a problem with it. Just to confirm that amd is not hideously
>broken beyond the point where _some_ people can use it just fine.
Likewise, though nearly all of our NFS activity is among FreeBSD boxen.
And we use NIS for the amd ma
< said:
> Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
> environments currently involve one of each (4.0 and 3.0), but I can
> certainly say that in none of these test environments does amd work at
> all.
Works just fine on a somewhat older 3.0 (which is still running the
I've been using amd on bleeding-edge current for the past year or so with
no problems - the servers in my case are Solaris 2.5.1 boxes.
I remember becoming extremely confused when I configured my first amd map
file, since there was no coherent documentation to be found at the time, but
I ended up
> Err On all of the machines where I use amd, I don't use -l syslog.
> I use -l /tmp/.automsg (or some other filename that lusers aren't likely
You're right, that does produce more information. Unfortunatly, not
enough to help diagnose the problem. :( I think something more
fundamental is br
> I use -l /tmp/.automsg (or some other filename that lusers aren't likely
..snip..
> I've found that am-utils is much more verbose than previous versions of
> amd so you may not want to leave it that way permanently ...
/var/log/amd.log and add it to /etc/newsyslog.conf.
Since this is what I use
Of all the gin joints in all the towns in all the world, Jordan K.
Hubbard had to walk into mine and say:
> > Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
> > Amd in 3.0 works for many. I won't defend that the new Amd works the
> > best with us, but then neither did the
"Jordan K. Hubbard" wrote:
> > Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
> > Amd in 3.0 works for many. I won't defend that the new Amd works the
> > best with us, but then neither did the old Amd.
>
> Erm, I haven't tried it between 3.0 and 3.0 boxes because all my t
> Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
> Amd in 3.0 works for many. I won't defend that the new Amd works the
> best with us, but then neither did the old Amd.
Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
environments currently involve on
> > Yes, to be consistent with the state of world WRT NFS. Or at least with
> > the leader -- Solaris. This has been the default in 3.0-C since the
> > am-utils import.
>
> Yeah, well, amd is a whole other ball of wax. That's clearly broken
> in both 3.0-stable and 4.0-current
Why is it clear
> Yes, to be consistent with the state of world WRT NFS. Or at least with
> the leader -- Solaris. This has been the default in 3.0-C since the
> am-utils import.
Yeah, well, amd is a whole other ball of wax. That's clearly broken
in both 3.0-stable and 4.0-current and we're going to have to re
> errors on "current" and checked the amd.conf file it was using.
> Version 3 of NFS seemed to be the default (!) for amd
Yes, to be consistent with the state of world WRT NFS. Or at least with
the leader -- Solaris. This has been the default in 3.0-C since the
am-utils import.
> it to version
In article <91639.917702...@zippy.cdrom.com>,
Jordan K. Hubbard wrote:
>
> As of the day before yesterday, I started getting all manner of NFS
> errors on "current" and checked the amd.conf file it was using.
> Version 3 of NFS seemed to be the default (!) for amd so I changed
> it to version 2 a
Scenario: Two machines, releng3.freebsd.org (running 3.0-stable) and
current.freebsd.org (running 4.0-current). releng3 has all the disk
space and is the NFS server. current is an NFS client and uses
releng3 for its CVS repository, FTP snapshot stashing area, etc.
As of the day before yesterday,
35 matches
Mail list logo
