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
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 s
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 getti
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
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
i
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 d
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
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
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 t
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.
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
te 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
> *
> * * make: don't know how to make Makefiles. Stop
> *
> * I've seen similar thing
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'. A
13 matches
Mail list logo
