FreebSD 3.5S to FreeBSD 4.x-STABLE problem
Hi! I'm trying to upgrade my system to 4.x-STABLE. The system runs a fresh 3.5-stable and I've cvsup'ed the source to RELENG_4. I've tried removing /usr/src and cvsuping, I've tried updating my existant /usr/src to RELENG_4. When I follow /usr/src/UPDATING I always get the same error: Extracting config.h (with variable substitutions) cc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/miniperl -c /usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5/miniperlmain.c ln -sf /usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5/op.c opmini.c cc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/miniperl -c opmini.c cc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/miniperl -L/usr/obj/usr/src/gnu/usr.bin/perl/miniperl/../libperl -static -o miniperl miniperlmain.o opmini.o /usr/obj/usr/src/gnu/usr.bin/perl/miniperl/../libperl/libperl.a -lm -lcrypt -lutil /usr/obj/usr/src/gnu/usr.bin/perl/miniperl/../libperl/libperl.a(pp_hot.o): In function `Perl_pp_aassign': pp_hot.o(.text+0x16a1): undefined reference to `setresuid' pp_hot.o(.text+0x16d4): undefined reference to `setresgid' What am I doing wrong? Thanks in advance, Regards, Tommy PS. Please CC me. DS. ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: passwd (still) broken in NIS environments
Do you have the same crypting algorithm on both ends ? (FreeBSD recently went to MD5 as a standard - Solaris most likely is still using DES) TfH Gerald Pfeifer [EMAIL PROTECTED] on 23/01/2001 11:40:07 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED](bcc: Thierry HERBELOT/FR/ALCATEL) Subject: Re: passwd (still) broken in NIS environments Not a single reply. Folks, this *is* a serious problem. We *are* willing to help anyone willing to fix this, but we just cannot fix every problem by ourself (even though we do try to help wherever possible, e.g. by providing FreeBSD portability patches for other software.) Gerald On Fri, 12 Jan 2001, Gerald Pfeifer wrote: Someone changed passwd/yppasswd such that now (on 4.2-RELEASE, put presumably also -STABLE) it is broken. NIS-Server: Solaris 2.6 /SPARC with current Recommended Patches NIS-Client: FreeBSD 4.2 /i386 Changing NIS password for user on NIS-server. Old Password: New password: Retype new password: passwd: failed to change NIS password: RPC: Server can't decode arguments When trying to debug this on the Solaris box, I got the following output from snoop: client - server PORTMAP C GETPORT prog=19 (NISPASSWD) vers=1 proto=UDP server - client PORTMAP R GETPORT port=819 client - server NISPASSWD C server - client RPC R (#196) XID=861861090 Garbage arguments Any ideas what might have caused this breakage? This worked w/o problems for the past three or four years (and corresponding FreeBSD releases). Anyone willing to help me debug this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Running with very high HZ ?
Hello, is there any limitations to the frequency of the clock ? more precisely : is it ok to run a recent PC (P-III + BX chipset) with HZ=5000 ? (I remember a comment in ipfw or dummynet advising the use of HZ=1000, is-it ok to go higher ?) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
make buildworld fails
Hi, "make buildworld" constantly fails on my 4.2-STABLE machine. I cvsup'ed freshly, but the problem persists. Here is the error log: -- stage 4: make dependencies -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.00503 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 par-depend === share/info === include === include/rpcsvc === lib === lib/csu/i386-elf === lib/libcom_err === lib/libcom_err/doc === lib/libcrypt === lib/../secure/lib/libcrypt === lib/msun === lib/libmd === lib/libncurses === lib/libradius === lib/libskey === lib/libtacplus === lib/libutil === lib/compat === lib/compat/compat1x === lib/compat/compat20 === lib/compat/compat21 === lib/compat/compat22 === lib/compat/compat3x.i386 === lib/libalias === lib/libatm === lib/libc === lib/libc_r === lib/libcalendar === lib/libcam === lib/libcompat === lib/libdevstat === lib/libdisk === lib/libedit === lib/libfetch === lib/libform === lib/libftpio === lib/libgnumalloc === lib/libipsec === lib/libipx === lib/libisc === lib/libkvm === lib/libmenu === lib/libncp === lib/libnetgraph === lib/libopie === lib/libpam === lib/libpam/modules === lib/libpam/modules/pam_cleartext_pass_ok === lib/libpam/modules/pam_deny === lib/libpam/modules/pam_opie === lib/libpam/modules/pam_permit === lib/libpam/modules/pam_radius === lib/libpam/modules/pam_skey === lib/libpam/modules/pam_ssh === lib/libpam/modules/pam_tacplus === lib/libpam/modules/pam_unix === lib/libpam/libpam === lib/libpanel === lib/libpcap === lib/libposix1e === lib/libresolv === lib/librpcsvc === lib/libsmdb === lib/libsmutil === lib/libss === lib/libstand === lib/libtelnet === lib/libusb === lib/libvgl === lib/libwrap === lib/libxpg4 === lib/liby === lib/libz === bin === bin/cat rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/bin/cat/cat.c cd /usr/src/bin/cat; make _EXTRADEPEND echo cat: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === bin/chio rm -f .depend mkdep -f .depend -a-I/usr/src/bin/chio/../../sys -I/usr/obj/usr/src/i386/usr/include /usr/src/bin/chio/chio.c cpp: Memory exhausted. mkdep: compile failed *** Error code 1 Stop in /usr/src/bin/chio. *** Error code 1 /usr/obj was deleted before "make buildworld". The last time I built world was Nov 21 (from 4.2-RELEASE to -STABLE). A friend of mine suggested that my mkdep binary might be broken. Any tips? lg, le -- Lukas Ertl eMail: [EMAIL PROTECTED] WWW-Redaktion Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID)Fax.: (+43 1) 4277-9140 der Universitt Wien To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld fails
Lukas Ertl wrote: Hi, "make buildworld" constantly fails on my 4.2-STABLE machine. I cvsup'ed freshly, but the problem persists. Here is the error log: -I/usr/obj/usr/src/i386/usr/include /usr/src/bin/chio/chio.c cpp: Memory exhausted. How much memory is in this box ? and what is running at the time of compilation ? -- Simon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld fails
On Tue, 23 Jan 2001, Simon Loader wrote: Lukas Ertl wrote: Hi, "make buildworld" constantly fails on my 4.2-STABLE machine. I cvsup'ed freshly, but the problem persists. Here is the error log: -I/usr/obj/usr/src/i386/usr/include /usr/src/bin/chio/chio.c cpp: Memory exhausted. How much memory is in this box ? and what is running at the time of compilation ? Sorry, I should have mentioned before: 96MB RAM, 128MB Swap. It looks ok while compiling, I tried in single user mode, too (where 96MB should be quite enough). If I try to issue the mkdep command on the shell in the chio dir it immediatly exits with the same error message. lg, le -- Lukas Ertl eMail: [EMAIL PROTECTED] WWW-Redaktion Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID)Fax.: (+43 1) 4277-9140 der Universitt Wien To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: passwd (still) broken in NIS environments
On Tue, 23 Jan 2001 [EMAIL PROTECTED] wrote: Do you have the same crypting algorithm on both ends ? (FreeBSD recently went to MD5 as a standard - Solaris most likely is still using DES) Yes, the Solaris NIS Server is using DES. However, as we don't have problems logging in, just changing passwords, I assume this isn't the reason? Or does passwd use MD5 nevertheless?? That might be an explanation! Hmm... Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
softupdates/NFS/vinum(?) panics
I have been getting frequent panics:
softdep_lock: locking against myself
These have been occurring since an incident on 16th January, where the
SCSI cable was accidentally unplugged on a running system, and vinum had
trouble recovering. That incident almost certainly caused some arbitrary
corruption to the filesystem; however, there is no obvious vinum
involvement in the more recent panics (except that the filesystem in
question is almost certainly the vinum one, as the other filesystems on
this machine are almost unused).
This suggests either:
1) The big crash left some corruption that fsck can't see but causes
subsequent problems.
2) There is some vinum interaction that happens to have been arisen
around this time (the filesystem has been growing gradually from
25% full when the system was commissioned in November to 50% now)
3) There is some softupdates problem unrelated to vinum.
For most of the period, the system has been running a kernel built from
-stable as at 1st January; over the weekend I upgraded to -stable (cvsup
on Friday 19th), but we've had 3 crashes this morning so that doesn't
appear to have helped.
All the dumps are rather similar, apparently serving an NFS write; here's
the latest one, and an older one:
IdlePTD 3162112
initial pcb at 2838e0
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 59099240 != new 59099240 || lbn 1 = 12
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014ea8b in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc014ee08 in poweroff_wait (junk=0xc02545c0, howto=-1025022464)
at ../../kern/kern_shutdown.c:556
#3 0xc01e7cf1 in acquire_lock (lk=0xc0277fdc)
at ../../ufs/ffs/ffs_softdep.c:263
#4 0xc01ebac4 in softdep_update_inodeblock (ip=0xc2e76600, bp=0xc7bf59b0,
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3643
#5 0xc01e6fed in ffs_update (vp=0xcfbabe00, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:106
#6 0xc01eed50 in ffs_sync (mp=0xc28da400, waitfor=2, cred=0xc0a3b900,
p=0xc0297c20) at ../../ufs/ffs/ffs_vfsops.c:987
#7 0xc017c587 in sync (p=0xc0297c20, uap=0x0) at ../../kern/vfs_syscalls.c:545
#8 0xc014e85e in boot (howto=256) at ../../kern/kern_shutdown.c:233
#9 0xc014ee08 in poweroff_wait (junk=0xc0254be0, howto=59099240)
at ../../kern/kern_shutdown.c:556
#10 0xc01e8eff in allocdirect_merge (adphead=0xc2f04c44, newadp=0xc2cc7f80,
oldadp=0xc2cd3200) at ../../ufs/ffs/ffs_softdep.c:1323
#11 0xc01ebc7d in merge_inode_lists (inodedep=0xc2f04c00)
at ../../ufs/ffs/ffs_softdep.c:3718
#12 0xc01ebb43 in softdep_update_inodeblock (ip=0xc2eb3d00, bp=0xc7b9fee4,
waitfor=1) at ../../ufs/ffs/ffs_softdep.c:3665
#13 0xc01e6fed in ffs_update (vp=0xcfbe9600, waitfor=1)
at ../../ufs/ffs/ffs_inode.c:106
#14 0xc01efcde in ffs_write (ap=0xcfb3bc88)
at ../../ufs/ufs/ufs_readwrite.c:544
#15 0xc01b09f4 in nfsrv_write (nfsd=0xc2eb3a00, slp=0xc2ce3200,
procp=0xce781400, mrq=0xcfb3bdfc) at vnode_if.h:363
#16 0xc01c7c9a in nfssvc_nfsd (nsd=0xcfb3be5c, argp=0x807c4a0 "", p=0xce781400)
at ../../nfs/nfs_syscalls.c:602
#17 0xc01c75ef in nfssvc (p=0xce781400, uap=0xcfb3bf80)
at ../../nfs/nfs_syscalls.c:306
#18 0xc022cb31 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = 0, tf_ebp = -1077936788, tf_isp = -810303532,
tf_ebx = 4, tf_edx = 1, tf_ecx = -3, tf_eax = 155, tf_trapno = 12,
tf_err = 2, tf_eip = 134518292, tf_cs = 31, tf_eflags = 647,
tf_esp = -1077937216, tf_ss = 47}) at ../../i386/i386/trap.c:1150
#19 0xc0221995 in Xint0x80_syscall ()
#20 0x8048135 in ?? ()
(kgdb)
Sample dump from January 1st kernel:
IdlePTD 3158016
initial pcb at 2823c0
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 36273280 != new 36273280 || lbn 4 = 12
syncing disks... panic: softdep_lock: locking against myself
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014db3f in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc014debc in poweroff_wait (junk=0xc0253200, howto=0)
at ../../kern/kern_shutdown.c:556
#3 0xc01e6b2d in acquire_lock (lk=0xc0276a7c)
at ../../ufs/ffs/ffs_softdep.c:263
#4 0xc01eade6 in softdep_fsync_mountdev (vp=0xce77a3c0)
at ../../ufs/ffs/ffs_softdep.c:3846
#5 0xc01eeef2 in ffs_fsync (ap=0xcfb39a80) at ../../ufs/ffs/ffs_vnops.c:134
#6 0xc01edbfa in ffs_sync (mp=0xc29d7000, waitfor=2, cred=0xc0a3b900,
p=0xc02966c0) at vnode_if.h:537
#7 0xc017b41f in sync (p=0xc02966c0, uap=0x0) at ../../kern/vfs_syscalls.c:545
#8 0xc014d91a in boot (howto=256) at ../../kern/kern_shutdown.c:233
#9 0xc014debc in poweroff_wait (junk=0xc0253820, howto=36273280)
at ../../kern/kern_shutdown.c:556
#10 0xc01e7d3b in allocdirect_merge (adphead=0xc2b30244, newadp=0xc305c100,
oldadp=0xc305c580) at ../../ufs/ffs/ffs_softdep.c:1323
#11 0xc01eaab9 in merge_inode_lists (inodedep=0xc2b30200)
at
Re: Dell PERC 3 support?
Alfred Perlstein stated: : A friend just asked me if we support the PERC 3 cards shipped in : Dell servers. If not, anyone have a recommendation for a controller : in the same price performance category that is supported? Alfred- The PERC 3 cards use the aac driver which was only very recently MFC'd (it should work with a recent snapshot). The card should work and you can download from Dell a Linux command line tool to do some work with the controller (you do need to build a custom kernel to use this that does not have aac statically defined and load the kld out of /boot/loader.conf (aac_load="YES") to get the linux ioctl support (it will not compile statically .. well, I could not get it to compile statically :). HTH, S -- Sean O'ConnellEmail: [EMAIL PROTECTED] Institute of Statistics and Decision Sciences Phone: (919) 684-5419 Duke University Fax: (919) 684-8594 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: passwd (still) broken in NIS environments
Gerald Pfeifer wrote: On Tue, 23 Jan 2001 [EMAIL PROTECTED] wrote: Do you have the same crypting algorithm on both ends ? (FreeBSD recently went to MD5 as a standard - Solaris most likely is still using DES) Yes, the Solaris NIS Server is using DES. However, as we don't have problems logging in, just changing passwords, I assume this isn't the reason? Or does passwd use MD5 nevertheless?? That might be an explanation! passwd uses whatever format you specified in /etc/login.conf for that users login class... Since the default crypt has been changing around with export restrictions being lifted etc. You should just put that you want DES in there... put in the line ":passwd_format=des:\" under "default:\" Good Luck! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dell PERC 3 support?
- Original Message - From: "Sean O'Connell" [EMAIL PROTECTED] The PERC 3 cards use the aac driver which was only very recently MFC'd (it should work with a recent snapshot). The card should work and you can download from Dell a Linux command line tool to do some work with the controller (you do need to build a custom kernel to use this that does not have aac statically defined and load the kld out of /boot/loader.conf (aac_load="YES") to get the linux ioctl support (it will not compile statically .. well, I could not get it to compile statically :). Have you gotten an aac card to work under STABLE? I tried with the following procedure within a week of the MFC of the aac driver. Card make was a HP Netraid 4M connected to a HP rackstorage/12 (6 disks, raid 5): 1) build STABLE kernel on updated STABLE machine 2) grab 5.0 snapshot (4.2 snap had no aac support) install disk, do install with 4.2 CD 3) on boot, copy 4.2-STABLE kernel with aac support to new system 4) reboot with 4.2 stable kernel, cvsup, make buildworld, buildkernel, instal, etc. 5) reboot 6) filesystem refuses to mount, "operation timed out..." During the cvsup operation the system would "pause" for 15-30 seconds for no apparent reason. A console switch to a systat -vmstat screen shows the aac disk at 100%. They'd stay at 100% and then the process would continue. I got the same kind of results during buildworld and installworld. My guess is that either my install process was too smart for my own good, or the driver didn't like my card. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libgcc_pic is gone (affects Wine port)
Quoting Gerald Pfeifer [EMAIL PROTECTED]: Due to a serious bug in the port of GCC used in the base system (see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21983) I and probably others had to explicitly link against libgcc_pic. This bug has been fixed (around 4.2-RELEASE), but also libgcc_pic is gone now, though I'm not sure whether that is directly related. So, what is a "portable" way of compiling sources both on 4.1-RELEASE and 5.0-CURRENT? On the former I need libgcc_pic, on the latter there is no libgcc_pic at all. Or, as this mainly affects the Wine port, should I just ignore older versions of FreeBSD? Does 4.2-RELEASE already have the fix to PR 21983? Gerald AFAIK, there's no libgcc_* in RELENG_4 anymore as well. Ask David [EMAIL PROTECTED] . To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dell PERC 3 support?
Shawn Barnhart stated: : Have you gotten an aac card to work under STABLE? I tried with the : following procedure within a week of the MFC of the aac driver. Card make : was a HP Netraid 4M connected to a HP rackstorage/12 (6 disks, raid 5): : : 1) build STABLE kernel on updated STABLE machine : 2) grab 5.0 snapshot (4.2 snap had no aac support) install disk, do install : with 4.2 CD : 3) on boot, copy 4.2-STABLE kernel with aac support to new system : 4) reboot with 4.2 stable kernel, cvsup, make buildworld, buildkernel, : instal, etc. : 5) reboot : 6) filesystem refuses to mount, "operation timed out..." : : During the cvsup operation the system would "pause" for 15-30 seconds for no : apparent reason. A console switch to a systat -vmstat screen shows the aac : disk at 100%. They'd stay at 100% and then the process would continue. I : got the same kind of results during buildworld and installworld. : : My guess is that either my install process was too smart for my own good, or : the driver didn't like my card. Shawn- I have been using a -current. However, -stable should support the controllers. Let me try the latest stable SNAP. Hmmm... GENERIC from the 20010122 SNAPSHOT found the controller and the containers, but sysinstall hasn't been trained to install on the containers :( S -- Sean O'ConnellEmail: [EMAIL PROTECTED] Institute of Statistics and Decision Sciences Phone: (919) 684-5419 Duke University Fax: (919) 684-8594 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export (was: Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, ReiserFS)
Note: when replying, please remove the (was: ) part of the Subject and the reiserfs-list from the recipients. On Tue, 23 Jan 2001, Guy Harris wrote: Perhaps the Linux server should, in "nfsd_access()", treat "nfserr_rofs" the same way it treats "nfserr_perm" and "nfserr_acces", and just say the access type is denied but the access query succeeded, doing the same thing that Solaris and a future release of the NetApp software will do. (It looks as if the FreeBSD NFS server already does that - it treats all errors from "nfsrv_access()" as meaning "access denied", not "access call failed", so it treats EROFS in that fashion. The same probably applies to other BSDs.) As for why the V2 client doesn't appear to have this problem, the V2 client doesn't make an ACCESS call, because NFS V2 doesn't have an ACCESS call to make. Ah, so it's a protocol difference which keeps Linux server - FreeBSD client compatibility here. If it *was* mounted read-only, was the ext2 file system also mounted read-only? If not, that might explain it. I looked again, closely, and found in /etc/exports: /space 192.168.0.0/255.255.255.0 /home 192.168.0.0/255.255.255.0(rw) I looked into exports(5) and found that exports assumes ro unless overriden with rw. Not reporting this and attributing the problem to ReiserFS instead of the RO mount (which looks strange to me as a response to a READ request) was my fault, and I apologize to the ReiserFS people for this bogus allegation. ReiserFS is now out of the play. As for why it's a problem with the FreeBSD client but not the Solaris client, I'm not sure - a quick look at the 4.2 client code doesn't seem to show any way in which the EROFS is "sticky" to the extent that it affects all client accesses, as it doesn't cache the result of an ACCESS call that failed. It may just be that the Solaris client just ignores NFS3ERR_ROFS from an ACCESS call and does an access check based on the permission bits, rather than returning EROFS, whilst the FreeBSD client returns EROFS; if ReiserFS is returning EROFS bogusly, that might cause the symptoms in question. Okay. So, as a conclusion, my original bug report boils down to: "You cannot mount read-only file systems with NFS v3 from a Linux 2.2.18 server to a FreeBSD 4.2-STABLE client. Use NFS v2 instead." The question remains: Linux kernel problem or FreeBSD client problem? -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
