On February 8, 2016 5:05 PM, Darren Tucker wrote: > On Tue, Feb 9, 2016 at 8:51 AM, Randall S. Becker > <rsbecker@xxxxxxxxxxxxx> wrote: > [...] > > I've got those logs. Unfortunately, hoping for more details. > > Me too. For example, a copy of those logs :-) > > > The logs do > > show the test failure, but no details in failed-sshd.log indicating a > > specific problem. Some of the formats are a bit wonky but I can live > > with those. Since you mentioned NFS, which could have been constrained > > by UDP packet sizes, and this platform sometimes cannot read beyond > > 56Kb off disk (in some situations), it may be the read of regress/data that is > failing. > > Any pointers where that is hiding so that I can verify that data is > > actually getting into sshd from the disk? > > Unfortunately debugging test failures is a pain that I don't have a good > answer too. > > One thing I do is edit regress/test-exec.sh to add a "set -x" at the top and > "exit 1" into the fail() function. Now when you run the test at the point it fails > you'll have the exact command that failed and exits without cleaning up, > leaving the keys and configs in place so you can rerun the command in you > shell, playing around with truss/strace/whatever your platform has. Tracked down to a bad 'dd' implementation. I'm working on fixing that. Likely of this problem being OpenSSH just dropped to under 5% ;) Thanks Darren. Cheers, Randall _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
