On 02/09/2011 08:21 PM, Gerry Reno wrote: > On 02/09/2011 08:04 PM, Gerry Reno wrote: > >> On 02/09/2011 07:21 PM, Gerry Reno wrote: >> >> >>> On 02/09/2011 06:43 PM, Larry Hall (Cygwin) wrote: >>> >>> >>> >>>> On 2/9/2011 5:56 PM, Gerry Reno wrote: >>>> >>>> >>>> >>>>> On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote: >>>>> >>>>> >>>>> >>>>>> On 2/9/2011 5:07 PM, Gerry Reno wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 02/09/2011 04:56 PM, Gerry Reno wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 2/8/2011 9:14 PM, Gerry Reno wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Something else I just discovered after upgrading to 1.7.7 is that >>>>>>>>>> I now >>>>>>>>>> have lost the ability to login via ssh. >>>>>>>>>> >>>>>>>>>> I have OpenSSH installed and running sshd as a service. Both >>>>>>>>>> password >>>>>>>>>> and keys accepted. But now neither means will work. >>>>>>>>>> >>>>>>>>>> # ssh -i keypair1.pem Administrator@MACHINE_IP >>>>>>>>>> Last login: Fri Feb 4 17:19:26 2011 from >>>>>>>>>> LOCAL_CLIENT_MACHINE >>>>>>>>>> Connection to MACHINE_IP closed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So I increased verbosity but did not see anything obvious. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> # ssh -v -i keypair1.pem Administrator@MACHINE_IP >>>>>>>>>> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009 >>>>>>>>>> debug1: Reading configuration data /etc/ssh/ssh_config >>>>>>>>>> debug1: Applying options for * >>>>>>>>>> debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22. >>>>>>>>>> debug1: Connection established. >>>>>>>>>> debug1: permanently_set_uid: 0/0 >>>>>>>>>> debug1: identity file keypair1.pem type -1 >>>>>>>>>> debug1: Remote protocol version 2.0, remote software version >>>>>>>>>> OpenSSH_5.8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Does reverting OpenSSH to 5.7 make a difference? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Downgraded to 5.7: >>>>>>>> >>>>>>>> bash-4.1$ sshd --version >>>>>>>> sshd: unknown option -- - >>>>>>>> OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> From client: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ssh -i keypair1.pem Administrator@MACHINE_IP >>>>>>>> Last login: Wed Feb 9 12:54:08 2011 from LOCAL_CLIENT_IP >>>>>>>> Connection to MACHINE_IP closed. >>>>>>>> >>>>>>>> >>>>>>>> Nope. Still have the same problem. Connection is made but >>>>>>>> immediately >>>>>>>> closes. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I'm suspecting this is related to running Cygwin 1.7. >>>>>>> >>>>>>> In looking back though some notes I started having bash shell problems >>>>>>> after upgrading from 1.5 to 1.7. >>>>>>> >>>>>>> Now on 1.7 if I try to run bash as a login shell it just gets "Bad >>>>>>> address" or segfault errors and immediately exits the shell which also >>>>>>> probably affects 'ssh'. >>>>>>> >>>>>>> I don't remember having any bash problems when I was running Cygwin >>>>>>> 1.5 >>>>>>> on this machine. My notes reflect screen copies showing bash able to >>>>>>> run as a login shell without any problem. >>>>>>> >>>>>>> >>>>>>> >>>>>> Yep, that's the way we all run by default (see cygwin.bat). I agree >>>>>> that if you're having problems getting bash to behave, it's best to >>>>>> focus >>>>>> on that issue first. Your ssh problems may just be another symptom of >>>>>> the same thing. How about sending cygcheck output >>>>>> (<http://cygwin.com/problems.html>)? There may be something helpful in >>>>>> that which someone on the list might pick up on. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Ok, ran a new cygcheck and attached it. >>>>> >>>>> >>>>> >>>> OK, thanks. What went wrong with the first installation? >>>> >>>> I notice that this is using TS. Can you try experiment with this machine >>>> locally? Or perhaps just try: >>>> >>>> <http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts> >>>> >>>> >>>> >>>> >>> I reduced DEP down to just Windows executables and dlls and then rebooted. >>> >>> And it actually seemed to make the problem worse: >>> >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done) >>> bash: /etc/profile.d/lapack0.sh: Bad address >>> bash-4.1$ >>> >>> >>> So DEP in is play here but sort of inverse from what I'd expect. There >>> was no switch now to totally disable it. I guess they want you to >>> fiddle with the registry to turn it all the way off. >>> >>> >>> >>> >>> >> I tried reinstalling bash and coreutils which installed ok but both >> their postinstall scripts have an abnormal exit 128 which is exactly >> what I was seeing previously. >> >> >> >> > So I try running lines from these postinstall scripts manually. > > In /etc/postinstall/bash.sh this code snippet kills everything: > > bash-4.1$ result=0 > bash-4.1$ test $result = 0 > 2 [main] bash 2484 sig_send: wait for sig_complete event > failed, signal -3 > 4, rc -1, Win32 error 6 > <SHELL IS DEAD> > > >From MSDN: > > ERROR_INVALID_HANDLE The handle is invalid. > 6 (0x6) > > > So what is this? > > Bad compilation? > Stack corruption? > > > > Ignore the last comment. Cannot run test from command line.
What I did find is that the postinstalls succeed when I run them from a Cygwin shell as Administrator: bash-4.1$ bash.exe -norc -noprofile /etc/postinstall/coreutils.sh bash-4.1$ echo $? 0 bash-4.1$ bash.exe --norc --noprofile /etc/postinstall/bash.sh bash-4.1$ echo $? 0 So why the exit code of 128 when setup runs these postinstalls? Regards, Gerry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple