Re: GRE Support in 4.X ???
The GRE "support" from the Squid patch is a {necessary, works ok} hack.
I was planning on integrating NetBSD's generic GRE support after 4.0 if
the appropriate people can be convinced that it is a good idea.
I believe you can also configure policy based routing on the Cisco to ship
the traffic to your caching server - without GRE encapsulation - and
achieve the same results.
-Chris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ssh_host_key?
I tried starting sshd via the rc.conf infrastructure after another buildworld/installworld this morning and still see the: sshd[166]: fatal: rsa_private_decrypt() failed error. I thought perhaps some of Peter's changes might have helped, but it seems to still boil down to the need to start sshd after ldconfig runs in /etc/rc. -Chris On Mon, 28 Feb 2000, Kris Kennaway wrote: On Mon, 28 Feb 2000, Jordan K. Hubbard wrote: Hmm. Whats the status of the sysinstall changes we were talking about? Namely, displaying rsaref on the correct vty during installation, and teaching it to pick up the RSA packages? I'm going to do this tonite, before I roll RC#3. Good boy :-) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
openssh: fatal: rsa_private_decrypt() failed
I find that if I start /usr/sbin/sshd manually everything works as expected. When I allow it to start via the rc scripts, I get upon connecting from my 1.2.27 ssh client sshd[190]: fatal: rsa_private_decrypt() failed There is a good chance that I have cruftlets from a prior sshd port installation but I am momentarily dazed and confused as to how that would affect the environment at rc.network time :| -c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh: fatal: rsa_private_decrypt() failed
It looks as though sshd is started prematurely (before ldconfig runs) in /etc/rc. I made the problem disappear on my system by starting sshd around the time inetd is started. -c On Fri, 25 Feb 2000, Chris Timmons wrote: I find that if I start /usr/sbin/sshd manually everything works as expected. When I allow it to start via the rc scripts, I get upon connecting from my 1.2.27 ssh client sshd[190]: fatal: rsa_private_decrypt() failed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is openssl/openssh working right yet for others?
I did a buildworld/installworld this afternoon and it works fine if I start /usr/bin/sshd from the command line as root. The way it starts from rc.network caused a problem for me which is described in another thread on this list. If you are still having trouble building, make sure you are getting an appropriate crypto distribution for your part of the world into your source tree. -Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hanging root device to da0s1a
Heh. Well, then you would have people asking you what ssigning root devices means :) The message seems to get garbled when the CAM probes (being done in the background) emit their messages. The c in my changing creates a new device called cda4 in my log file: Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! cda4 at ahc1 bus 0 target 8 lun 0 da4: SEAGATE ST39102LW 0005 Fixed Direct Access SCSI-2 device -Chris On Wed, 19 May 1999, Jordan K. Hubbard wrote: No offense, but can we use something like assigning in place of the rather loaded word hanging? I can just see the user bug reports now; My root device is hanging! It says so every time I boot! HELP! :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
hang going multiuser
I built and installed world+kernel last evening after the ibcs2 fix was committed to unbreak the build. When running either the new kernel or the pre-branch kernel from last month, I hang up on the way to multi-user. I can boot single-user, get my ccd drive going, get the network going, run cvs with an nfs-mounted repo, etc, etc. I can escape to the debugger; ps tells me I have processes 0-5 plus two sh's. init is in the 'wait' state. Is there a command to show which process is currently executing? Maybe it is telling me that and I can't see it. The trace (same for both kernels) shows: vm_map_madvise madvise syscall(2f,2f,80a1000,1000,efb94ba8) Xint0x80_syscall I also updated my /etc files, but even so the system shouldn't hang like this if I missed something. Something that was installed with the world is hanging up. -Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world dying
Hmmm, I zapped my /usr/obj clean around 1100PST 19/Jan/1999 and made world just fine. Try starting with an empty /usr/obj. You can pretty much glean from reading -current whether or not most people are building it or if it is broken. -questions is more for general freebsd issues. -Chris On Tue, 19 Jan 1999, Aaron D. Gifford wrote: I'm still trying to upgrade from 3.0-RELEASE to 3.0-CURRENT unsuccessfully. It used to die in perl, then that was fixed, but for the past 2 days, it has been dying in /usr/src/sys/boot/i386/libi386. Is this a known problem? Yes, I'm a CURRENT newbie, but hopefully only until the split to 3.1 when I can hopefully then play with 3.1-STABLE. Are questions such as the above better addressed to -questions or -current? Thanks. Hoping to catch a cvsup when the source tree will build, Aaron out. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS problem found - pleaes try this patch.
Good work! I have to run at the moment but it looks like you nailed this
one. Your explanation coincides perfectly with the symptoms.
Thanks!
-Chris
On Mon, 18 Jan 1999, Matthew Dillon wrote:
Ok, I believe I have found the bug. Please test the patch included below.
I was able to make /usr/ports/x11/XFree86-contrib after applying this
patch ( and it was screwing up prior to that ).
The problem is in getblk() - code was added to validate the buffer and
to clear B_CACHE if the bp was not entirely valid. The problem is
that NFS uses B_CACHE to flag a dirty buffer that needs to be written out!
Additionally, a write() to an NFS based file may write data that is not
on a DEV_BSIZE'd boundry which causes a subsequent read() to improperly
clear B_CACHE.
There are almost certainly more problems like this -- using B_CACHE to
mark a buffer dirty is just plain dumb, it's no wonder NFS is so screwed
up!
-Matt
Matthew Dillon
dil...@backplane.com
Index: kern/vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.192
diff -u -r1.192 vfs_bio.c
--- vfs_bio.c 1999/01/12 11:59:34 1.192
+++ vfs_bio.c 1999/01/18 13:25:27
@@ -1364,6 +1364,7 @@
break;
}
}
+
boffset = (i PAGE_SHIFT) - (bp-b_offset PAGE_MASK);
if (boffset bp-b_dirtyoff) {
bp-b_dirtyoff = max(boffset, 0);
@@ -1457,7 +1458,14 @@
}
KASSERT(bp-b_offset != NOOFFSET,
(getblk: no buffer offset));
+#if 0
/*
+ * XXX REMOVED XXX - this is bogus. It will cause the
+ * B_CACHE flag to be cleared for a partially constituted
+ * dirty buffer (NFS) that happens to have a write that is
+ * not on a DEV_BSIZE boundry!! XXX REMOVED
+ */
+ /*
* Check that the constituted buffer really deserves for the
* B_CACHE bit to be set. B_VMIO type buffers might not
* contain fully valid pages. Normal (old-style) buffers
@@ -1478,6 +1486,7 @@
poffset = 0;
}
}
+#endif
if (bp-b_usecount BUF_MAXUSE)
++bp-b_usecount;
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
NFS: likely problem is vfs_bio.c rev 1.188
John Polstra did some leg work and found a few candidate commits which he suggested backing out one by one to see if they affected the current situation with NFS. On the server I downgraded vfs_bio.c to rev 1.187 rebooted; no luck. I then installed the same kernel (with the downgraded vfs_bio.c) to the client. Bingo. With both NFS client server machine running rev 1.187, the problem so far as building XFree86-contrib from an NFS mounted /usr/ports disappears. As Chuck Robey noted, it seems like the client's writes are not completely being committed to the server, which results in partially baked files which are truncated. Unfortunately -r1.188 -r1.187 doesn't apply cleanly, so there's some work to be done by Eivind to adapt his subsequent commits if we were to say, back out 1.188 prior to the branch. -Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel build breaks after the latest cvsup
You probably need to add kbd0 and update sc0 in your kernel config file. Have a look in the GENERIC kernel config to see how it is done now... On Sat, 16 Jan 1999, Rajesh Vaidheeswarran wrote: Hello folks, I just did a cvsup and tried rebuilding world and the kernel, but I keep getting an error during the kernel linking stage. loading kernel syscons.o: In function `scvidprobe': syscons.o(.text+0x231): undefined reference to `vid_configure' syscons.o(.text+0x24e): undefined reference to `vid_allocate' syscons.o(.text+0x26b): undefined reference to `vid_get_adapter' ... and many more... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
Actually the good news is that the problems I see with the XFree86-contrib port are absolutely reproducible. To be sure I set the test case up on a different set of machines than the pair at home on which I first noticed it. I'll dig a little more this weekend and perhaps I can correlate my ktrace data against the tcpdump trace. -Chris On Fri, 15 Jan 1999, Satoshi Asami wrote: * From: as...@freebsd.org (Satoshi Asami) * * * From: Chris Timmons skyn...@opus.cts.cwu.edu * * * make: don't know how to make Makefiles. Stop * * I've seen similar things, but they went away when I reduced the load * (other compilations in my case) on the server. How busy is your * server? Forgot to mention, this happens with a read-only NFS tree too. I was running builds on the client with a shared /usr/ports and WRKDIRPREFIX pointing to a local directory, and the build will topple over in the middle unable to find a Makefile on the server or something. That is the problem that went away with the server load. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
NFS woes: getting worse?
I have duplicated on two pairs of machines a case whereby you have two -current machines as of ~20:00 UTC 1999/Jan/14 which cannot interoperate via NFS without corruption. To repeat: create a ports tree on one, mount it on the other. Have the client 'cd /usr/ports/x11/XFree86-contrib; make'. As soon as it extracts the distfile and starts working, it blows up: === Configuring for XFree86-contrib-3.3.3 mv -f Makefile Makefile.bak imake -DUseInstalled -I/usr/X11R6/lib/X11/config make Makefiles making Makefiles in programs... mv -f Makefile Makefile.bak making Makefiles in programs/ico... mv -f Makefile Makefile.bak make: don't know how to make Makefiles. Stop making Makefiles in programs/listres... mv -f Makefile Makefile.bak etc. Softupdates and version -2 mounts do not affect the problem, and it builds fine on a local disk. I have done some work with ktrace and tcpdump and can see that files are being returned shorter from the NFS server than they really are. For example, on the server machine's local disk, ktrace showed one file read this way: 14820 make RET read 0 14820 make RET read 8192/0x2000 14820 make RET read 8192/0x2000 14820 make RET read 2845/0xb1d 14820 make RET read 0 On the client side, I isolated the same part of the corresponding ktrace and saw that it got: 13748 make RET read 0 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 512/0x200 13748 make RET read 114/0x72 13748 make RET read 0 18034 bytes read by the NFS client, 19229 bytes read on the local system! The file shown in the kdump output above is Makefile (see path below), and we can see that it's true size is 19229. This is just one instance of the problem. skynyrd:/usr/ports/x11/XFree86-contrib/work/contrib# ls -l programs/ico/ total 64 -rw-r--r-- 1 root wheel282 Jun 4 1994 Imakefile -rw-r--r-- 1 root wheel 19229 Jan 14 19:53 Makefile SO, it looks like there is some sort of arithmetic error going on? I have copious amounts of debugging info here, but have to run at the moment. If someone else can reproduce the problem I can send-pr all of it Sigh. -Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
