X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-48.4 required=5.0	tests=AWL,BAYES_00,BOTNET,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,TW_YG,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-id: <4D534402.1070400@verizon.net>
Date: Wed, 09 Feb 2011 20:48:50 -0500
From: Gerry Reno <greno AT verizon DOT net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4
MIME-version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.7:  after upgrade lost ability to login via ssh
References: <4D51F868 DOT 6010000 AT verizon DOT net> <4D52131F DOT 9060603 AT cygwin DOT com> <4D530D72 DOT 7000302 AT verizon DOT net> <4D531023 DOT 6070807 AT verizon DOT net> <4D5316A4 DOT 7080902 AT cygwin DOT com> <4D531B83 DOT 3080000 AT verizon DOT net> <4D5326B2 DOT 7010203 AT cygwin DOT com> <4D532F7F DOT 7010103 AT verizon DOT net> <4D5339AC DOT 3010003 AT verizon DOT net> <4D533DB1 DOT 1000607 AT verizon DOT net>
In-reply-to: <4D533DB1.1000607@verizon.net>
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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 AT 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 AT 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 AT 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