Re: cygutils Postinstall Script Errors With Exit Code 128
exit code 128 http://www.keepdynamic.com/barcoding/asp-net-barcode-generator.shtml Generally, this kind of failure stems from a few common problems: 1. The existence of another (often old) cygwin1.dll. Find it. Remove it. 2. http://cygwin.com/acronyms/#BLODA. Remove BLODA. 3. Possibly fork failures. Install the rebase package and run rebaseall after reading the README in /usr/share/doc/Cygwin. Also, make sure you're using the latest 'setup.exe' as found at cygwin.com. Beware of proxies along your path that could be caching an old version. You want version 2.697. Problem reports: http://cygwin.com/problems.html If it's none of the above, please provide cygcheck output as requested by the link above. -- View this message in context: http://cygwin.1069669.n5.nabble.com/Re-cygutils-Postinstall-Script-Errors-With-Exit-Code-128-tp99002p109846.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 6/5/2013 12:47 PM, Yaakov (Cygwin/X) wrote: On 2013-05-31 03:34, Corinna Vinschen wrote: On May 30 16:50, Charles Wilson wrote: If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln What about cygstart mkshortcut readshortcut? These may be used by postinstall scripts, the other stuff is extra, afaics. Agreed. Ack. IMO man1 pages should be packaged together with their executables. Ack. So, as result, we should do this for a start: - cygwin-doc drops Base from the categories. - dos2unix adds Base to the categories. - cygutils drops dos2unix from requires. Yes. The man3 and info pages definitely don't need to be in Base, but it would be nice if the man1 pages were packaged with cygwin. Is that possible? Otherwise, this sounds good to me. Sure, I can do that. I'll roll a new release tonight (for both 32- and 64-). -- Chuck -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 2013-05-31 03:34, Corinna Vinschen wrote: On May 30 16:50, Charles Wilson wrote: If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln What about cygstart mkshortcut readshortcut? These may be used by postinstall scripts, the other stuff is extra, afaics. Agreed. cygutils-extra (Util): [requires: cygutils] almost everything else, including documentation and man pages (even for the exe's in the Base package) IMO man1 pages should be packaged together with their executables. cygutils-x11 (X11): [requires: cygutils] the two desktop files, and the postinstall scripts that handle them This way, any package that currently requires: cygutils will almost certainly get the tool it is looking for, without having to change its requires line (and besides, if cygutils is in Base you'd get those anyway). So, as result, we should do this for a start: - cygwin-doc drops Base from the categories. - dos2unix adds Base to the categories. - cygutils drops dos2unix from requires. And additionally you propose the above change to cygutils. Sounds good to me. Yaakov? The man3 and info pages definitely don't need to be in Base, but it would be nice if the man1 pages were packaged with cygwin. Is that possible? Otherwise, this sounds good to me. Yaakov -- 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
Re: Postinstall Script Errors With Exit Code 128
From: Larry Hall (Cygwin) reply-to-list-only-lh at cygwin dot com To: cygwin at cygwin dot com, Date: 05/29/2013 03:51 PM Subject: Re: Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On 5/29/2013 3:18 PM, Paul.Nickerson at desknetinc dot com wrote: So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. Possibly. You may have a BLODA problem ( http://cygwin.com/acronyms/#BLODA), whether known or unknown. If so, getting rid of it will certainly help. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. Interesting. Maybe there's some Windows permission problems in the directory you were running from? I have fixed it. Thank you for your help. I have a few other AWS EC2 instances. One other was having trouble with Cygwin install, and none of the rest were. I tried comparing installed applications, but got nowhere. I also tried installing Windows updates on the troubled system, and copying the cygwin from a healthy system to the troubled one. Neither attempt worked. I had looked into folder permissions before, which all looked fine, and tried installing to another folder and even another drive, but that hadn't helped. I then used WinDbg to run C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/000-cygwin-post-install.sh, and I think I got this error: SetContext failed, 0x8007001F. Looking online, it seems that code is associated with A device attached to the system is not functioning. I have already rebooted a bunch of times. I used Belarc Advisor to grab the virtual hardware version. Belarc Advisor said the System Model / Main Circuit Board / BIOS on both troubled instances was Xen HVM domU 3.1.2-92.1.13.el5., while on the other working instances it was Xen HVM domU 3.4.3-2.6.18 09/01/2012. So, I shut down the instance (I use EBS volumes), created an AMI from it, created an Instance from the AMI, and started up that instance. This has the effect of applying a new virtual hardware if available (proven by the fact that I get a new Instance ID), as well as moving to different physical hardware. After this, Belarc Advisor reported the good virtual hardware version. And, I was able to successfully install and use Cygwin normally. :) I have attached the output of running that bash.exe command inside WinDbg, just in case it's useful for anything. Again, thank you for you help. ~ Paul Microsoft (R) Windows Debugger Version 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/000-cygwin-post-install.sh Symbol search path is: C:\cygwin\usr\lib\debug\usr\bin Executable search path is: ModLoad: `0040 `0048e000 image`0040 ModLoad: `77ec `77ffc000 ntdll.dll ModLoad: `6b00 `6b046000 C:\WINDOWS\system32\wow64.dll ModLoad: `6b28 `6b2ca000 C:\WINDOWS\system32\wow64win.dll ModLoad: `78b8 `78b89000 C:\WINDOWS\system32\wow64cpu.dll (8c.fa8): Break instruction exception - code 8003 (first chance) *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!DbgBreakPoint: `77ef24f0 cc int 3 0:000 g ModLoad: `77d4 `77eb3000 NOT_AN_IMAGE ModLoad: `7d4c `7d5f NOT_AN_IMAGE ModLoad: `7d60 `7d6f C:\WINDOWS\SysWOW64\ntdll32.dll ModLoad: `77d4 `77eb3000 NOT_AN_IMAGE ModLoad: `77c2 `77d2c000 NOT_AN_IMAGE ModLoad: `7d4c `7d5f C:\WINDOWS\syswow64\kernel32.dll ModLoad: `6100 `6148 C:\cygwin\bin\cygwin1.dll ModLoad: `6fda `6fdaf000 C:\cygwin\bin\cygintl-8.dll ModLoad: `6fdb `6feac000 C:\cygwin\bin\cygiconv-2.dll ModLoad: `6fa7 `6fa9d000 C:\cygwin\bin\cygreadline7.dll ModLoad: `6fb2 `6fb61000 C:\cygwin\bin\cygncursesw-10.dll ModLoad: `6ff9 `6ffa8000 C:\cygwin\bin\cyggcc_s-1.dll ModLoad: `7d93 `7da0 C:\WINDOWS\syswow64\USER32.dll ModLoad: `7d80 `7d89 C:\WINDOWS\syswow64\GDI32.dll ModLoad: `7d1e `7d27c000 C:\WINDOWS\syswow64\ADVAPI32.dll ModLoad: `7da2 `7db0 C:\WINDOWS\syswow64\RPCRT4.dll ModLoad: `7d8d `7d92 C:\WINDOWS\syswow64\Secur32.dll (8c.fa8): WOW64 breakpoint - code 401f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\SysWOW64\ntdll32.dll - ntdll32
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On May 30 16:50, Charles Wilson wrote: On 5/30/2013 5:08 AM, Corinna Vinschen wrote: That sounds strange. Was cygwin-doc always in Base? It contains the cygwin docs and basic man pages but that doesn't really qualify for the Base category. [...] One caveat, mentioned in my other reply: cygutils' own requires: line lists dos2unix, so right now a Base install gets that package. This is probably desirable, but if we (effectively) remove cygutils from a Base install, we probably would want to add dos2unix to Base explicitly. If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln What about cygstart mkshortcut readshortcut? These may be used by postinstall scripts, the other stuff is extra, afaics. cygutils-extra (Util): [requires: cygutils] almost everything else, including documentation and man pages (even for the exe's in the Base package) cygutils-x11 (X11): [requires: cygutils] the two desktop files, and the postinstall scripts that handle them This way, any package that currently requires: cygutils will almost certainly get the tool it is looking for, without having to change its requires line (and besides, if cygutils is in Base you'd get those anyway). So, as result, we should do this for a start: - cygwin-doc drops Base from the categories. - dos2unix adds Base to the categories. - cygutils drops dos2unix from requires. And additionally you propose the above change to cygutils. Sounds good to me. Yaakov? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
Re: Postinstall Script Errors With Exit Code 128
On 5/31/2013 2:29 AM, paul.nicker...@desknetinc.com wrote: From: Larry Hall (Cygwin) reply-to-list-only-lh at cygwin dot com To: cygwin at cygwin dot com, Date: 05/29/2013 03:51 PM Subject: Re: Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On 5/29/2013 3:18 PM, Paul.Nickerson at desknetinc dot com wrote: So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. Possibly. You may have a BLODA problem ( http://cygwin.com/acronyms/#BLODA), whether known or unknown. If so, getting rid of it will certainly help. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. Interesting. Maybe there's some Windows permission problems in the directory you were running from? I have fixed it. Thank you for your help. I have a few other AWS EC2 instances. One other was having trouble with Cygwin install, and none of the rest were. I tried comparing installed applications, but got nowhere. I also tried installing Windows updates on the troubled system, and copying the cygwin from a healthy system to the troubled one. Neither attempt worked. I had looked into folder permissions before, which all looked fine, and tried installing to another folder and even another drive, but that hadn't helped. I then used WinDbg to run C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/000-cygwin-post-install.sh, and I think I got this error: SetContext failed, 0x8007001F. Looking online, it seems that code is associated with A device attached to the system is not functioning. I have already rebooted a bunch of times. I used Belarc Advisor to grab the virtual hardware version. Belarc Advisor said the System Model / Main Circuit Board / BIOS on both troubled instances was Xen HVM domU 3.1.2-92.1.13.el5., while on the other working instances it was Xen HVM domU 3.4.3-2.6.18 09/01/2012. So, I shut down the instance (I use EBS volumes), created an AMI from it, created an Instance from the AMI, and started up that instance. This has the effect of applying a new virtual hardware if available (proven by the fact that I get a new Instance ID), as well as moving to different physical hardware. After this, Belarc Advisor reported the good virtual hardware version. And, I was able to successfully install and use Cygwin normally. :) I have attached the output of running that bash.exe command inside WinDbg, just in case it's useful for anything. Again, thank you for you help. You're welcome. Thanks for your efforts in tracking this down and reporting back. I suspect it will help others in the future if they see similar issues. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On May 29 18:51, Yaakov (Cygwin/X) wrote: But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. That sounds strange. Was cygwin-doc always in Base? It contains the cygwin docs and basic man pages but that doesn't really qualify for the Base category. Also, why does cygwin-doc depend on cygutils at all? It only contains info and man pages, so the deps should be coreutils and man, but nothing else, AFAICS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/29/2013 7:51 PM, Yaakov (Cygwin/X) wrote: On 2013-05-29 17:43, Charles Wilson wrote: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml Right, because packages providing those kind of files usually need those commands to be run in order for them to take effect; see below. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... Perl? I thought it was Python, due to a false positive in the dependency detection with glib2.0, which I fixed on sourceware. You're right, it was python. One of the gigantic p* packages, anyway... But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. I've got email from 2006 [1] where the following was mentioned: Since cygutils is required by some packages in the Base category, ... so maybe at one point, several packages required it. It's also possible, at one point, that we explicitly wanted it to be in that category, as it provided our d2u/u2d tools. Obviously now that we have an standalone u2d package that isn't an issue (but I note that dos2unix is NOT in Base, but IS listed as requirement for cygutils. So if we take action to (effectively) remove cygutils from Base, then dos2unix will also go missing. The problem here is that cygutils is not primarily a desktop-oriented package. Most packages providing XDG menu and mime entries *are*, so these dependencies not only mandatory, but quite modest by those standards. I added these files because it allows better integration between desktop file managers (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it easy to launch an EXE/MSI installer from one's Downloads folder. However, most people use cygutils outside of the desktop, so particularly if its pulled into Base, these deps would be more than the bare-minimal system. If cygutils should be in Base, the solution is probably one of the following: * provide these files (and postinstall scripts) in a 'cygutils-x11' subpackage; * OR move them to another package (not sure which yet) which will already be installed in desktop scenarios, and adding cygutils as a dependency thereto. For now, should we go with the first option? Yes, that's probably the best way to go. I'll roll a new release with that change, for both 32- and 64- cygwin, soon. (Need to investigate the recent resurrected report about cygdrop and privelege dropping first). [1] http://cygwin.com/ml/cygwin-apps/2006-03/msg00117.html -- Chuck -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/30/2013 5:08 AM, Corinna Vinschen wrote: On May 29 18:51, Yaakov (Cygwin/X) wrote: But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. That sounds strange. Was cygwin-doc always in Base? It contains the cygwin docs and basic man pages but that doesn't really qualify for the Base category. Over the years, cygutils has lost a lot of content to other packages (standalone, util-linux, etc), and gained a smaller collection of new tools. In the past, cygutils may have been considered more central than its current incarnation deserves. current contents of cygutils: banner.exe getclip.exe readshortcut.exe conv.exeipcksemstat.exe cygdrop.exe lpr.exe semtool.exe cygicons-0.dll mkshortcut.exe shmtool.exe cygstart.exemsgtool.exe winln.exe dump.exeputclip.exe Other than cygstart, cygdrop and lpr(?), and maybe the new winln, I can't see that any of those really deserve to be in Base. If cygwin-doc is truly the only thing pulling cygutils into Base, then (a) removing cygutils from cygwin-doc's requires:, or (b) removing cygwin-doc from Base, would have the (desired?) effect of removing cygutils from Base. One caveat, mentioned in my other reply: cygutils' own requires: line lists dos2unix, so right now a Base install gets that package. This is probably desirable, but if we (effectively) remove cygutils from a Base install, we probably would want to add dos2unix to Base explicitly. If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln cygutils-extra (Util): [requires: cygutils] almost everything else, including documentation and man pages (even for the exe's in the Base package) cygutils-x11 (X11): [requires: cygutils] the two desktop files, and the postinstall scripts that handle them This way, any package that currently requires: cygutils will almost certainly get the tool it is looking for, without having to change its requires line (and besides, if cygutils is in Base you'd get those anyway). Also, why does cygwin-doc depend on cygutils at all? It only contains info and man pages, so the deps should be coreutils and man, but nothing else, AFAICS. Maybe it used to install a shortcut to the documentation into the Start Menu, and needed mkshortcut to do so? It doesn't do that anymore (if it ever did), so the dependency on cygutils sure seems superfluous. -- Chuck -- Chuck -- 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
Re: cygutils Postinstall Script Errors With Exit Code 128
On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: I am attempting to install Cygwin, and am getting errors near the end of the process. I am using version 2.774 of setup.exe on Microsoft Windows Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote desktopping in. In the Cygwin Setup GUI, after it goes through the install procedure, I get a window titled Postinstall script errors, with the below output text: Package: base-cygwin 000-cygwin-post-install.sh exit code 128 Package: terminfo terminfo.sh exit code 128 Package: bash bash.sh exit code 128 Package: coreutils coreutils.sh exit code 128 Package: _autorebase autorebase.bat exit code -1073741819 Package: base-files base-files-profile.sh exit code 2816 base-files-mketc.sh exit code 128 Package: cygutils cygutils.sh exit code 127 Package: man man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database /usr/bin/update-mime-database /usr/share/mime If I then open Cygwin Terminal using the Desktop shortcut, I get a window titled -sh and a prompt that says -sh-4.1$. The command ls returns -sh: ls: command not found, but echo works. I have tried re-running setup.exe, removing the cygwin directory, re-downloading the setup.exe, removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, setting Turn on DEP for essential Windows programs and services only and rebooting, altering file and folder permissions, deleting the cache and using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in Windows to remote desktop in, but none of this changes the behavior. I have an odd and possibly related behavior. If I open Command Prompt, run C:\cygwin\bin\bash.exe --norc --noprofile to get a bash-4.1$ prompt, then in there run if [ foo = foo ]; then echo Expression evaluated as true.; fi the bash prompt will exit back to command prompt, and %ERRORLEVEL% has been set to 128. Running that if statement in the window brought up by the Cygwin Terminal Desktop shortcut will sometimes make the window close, but not always. I have not explored how I might be triggering the Desktop shortcut to work or not work. I have attached setup.log and setup.log.full. When I run cygcheck -s -v -r cygcheck.out, it hangs and does not exit. Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual cores). It does write some things out to cygcheck.out, which I have attached. When I run the command in Command Prompt without redirecting output to a file, I get a little more information before it hangs, which I have copied out of the command prompt and attached as cygcheck-no-redirect.out. I do not know why it's saying I have multiple cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. Looking at cygcheck.out, I am running in a Terminal Service session, which makes sense as I am remote desktopped in. My problem might be related to FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts ), but the DEP solution is not helping me. I tried running C:\cygwin\binpeflags --tsaware=true --tsaware * in Command Prompt, but it did not change anything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Re: Postinstall Script Errors With Exit Code 128
Paul.Nickerson at desknetinc dot com wrote on 05/28/2013 03:43:11 PM: From: Paul.Nickerson at desknetinc dot com To: cygwin at cygwin dot com, Date: 05/28/2013 03:43 PM Subject: Postinstall Script Errors With Exit Code 128 I am attempting to install Cygwin, and am getting errors near the end of the process. I am using version 2.774 of setup.exe on Microsoft Windows Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote desktopping in. In the Cygwin Setup GUI, after it goes through the install procedure, I get a window titled Postinstall script errors, with the below output text: Package: base-cygwin 000-cygwin-post-install.sh exit code 128 Package: terminfo terminfo.sh exit code 128 Package: bash bash.sh exit code 128 Package: coreutils coreutils.sh exit code 128 Package: _autorebase autorebase.bat exit code -1073741819 Package: base-files base-files-profile.sh exit code 2816 base-files-mketc.sh exit code 128 Package: cygutils cygutils.sh exit code 127 Package: man man.sh exit code 128 If I then open Cygwin Terminal using the Desktop shortcut, I get a window titled -sh and a prompt that says -sh-4.1$. The command ls returns -sh: ls: command not found, but echo works. I have tried re-running setup.exe, removing the cygwin directory, re- downloading the setup.exe, removing HKEY_LOCAL_MACHINE\SOFTWARE \Wow6432Node\Cygwin from the registry, setting Turn on DEP for essential Windows programs and services only and rebooting, altering file and folder permissions, deleting the cache and using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in Windows to remote desktop in, but none of this changes the behavior. I have an odd and possibly related behavior. If I open Command Prompt, run C:\cygwin\bin\bash.exe --norc --noprofile to get a bash-4.1$ prompt, then in there run if [ foo = foo ]; then echo Expression evaluated as true.; fi the bash prompt will exit back to command prompt, and %ERRORLEVEL% has been set to 128. Running that if statement in the window brought up by the Cygwin Terminal Desktop shortcut will sometimes make the window close, but not always. I have not explored how I might be triggering the Desktop shortcut to work or not work. I have attached setup.log and setup.log.full. When I run cygcheck -s -v -r cygcheck.out, it hangs and does not exit. Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual cores). It does write some things out to cygcheck.out, which I have attached. When I run the command in Command Prompt without redirecting output to a file, I get a little more information before it hangs, which I have copied out of the command prompt and attached as cygcheck-no-redirect.out. I do not know why it's saying I have multiple cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. Looking at cygcheck.out, I am running in a Terminal Service session which makes sense as I am remote desktopped in. My problem might be related to FAQ #2.14 (http://cygwin.com/faq- nochunks.html#faq.setup.setup-fails-on-ts), but the DEP solution is not helping me. I tried running C:\cygwin\binpeflags -- tsaware=true --tsaware * in Command Prompt, but it did not change anything. [attachment setup.log.full deleted by Paul Nickerson/DeskNetInc] [attachment cygcheck.out deleted by Paul Nickerson/DeskNetInc] [attachment setup.log deleted by Paul Nickerson/DeskNetInc] [attachment cygcheck-no-redirect.out deleted by Paul Nickerson/DeskNetInc] Larry Hall (Cygwin) reply-to-list-only-lh at cygwin dot com Tue, 28 May 2013 17:15:00 -0400 Try removing GS and OpenVPN from you path and try installing again. If that doesn't work, you might try installing Just for Me. Sorry I'm replying to my original post. I forgot to actually subscribe to the mailing list, and didn't get your message in my inbox. I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. -- 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
Re: Postinstall Script Errors With Exit Code 128
On 5/29/2013 12:04 PM, Paul.Nickerson wrote: snip I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. This list has seen the occasional question about AWS and Cygwin in the past but AFAIK, no one active on the list is using AWS with Cygwin. My best suggestion at this point is to consult the Amazon folks to get their input. The fact that cygcheck doesn't run to completion really points to an issue outside of Cygwin proper, since cygcheck is a vanilla Windows program. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: Postinstall Script Errors With Exit Code 128
cygwin-owner at cygwin dot com wrote on 05/29/2013 12:28:30 PM: From: Larry Hall (Cygwin) reply-to-list-only-lh at cygwin dot com To: cygwin at cygwin dot com, Date: 05/29/2013 12:29 PM Subject: Re: Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On 5/29/2013 12:04 PM, Paul.Nickerson wrote: snip I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. This list has seen the occasional question about AWS and Cygwin in the past but AFAIK, no one active on the list is using AWS with Cygwin. My best suggestion at this point is to consult the Amazon folks to get their input. The fact that cygcheck doesn't run to completion really points to an issue outside of Cygwin proper, since cygcheck is a vanilla Windows program. -- Larry I tried removing cygwin1.dll from the bin directory and re-running cygcheck.exe, and it ran to completion. When I ran it, I got the below popup and error, and I have attached the produced output, created with C:\cygwin\bincygcheck -s -v -r -h cygcheck.out 21. I got the error after the Path: and before SysDir:. --- id.exe - Unable To Locate Component --- This application has failed to start because cygwin1.dll was not found. Re-installing the application may fix this problem. --- OK --- garbled output from 'id' command - no uid= found Looking at cygcheck's source, it looks like after displaying Warning: cygwin1.dll not found on your path or Warning: There are multiple cygwin1.dlls on your path, it runs dump_dodgy_apps() (which gives no output when I get cygcheck to run through to completion), and then it runs dump_sysinfo_services() (which gives the output Can't find the cygrunsrv utility, skipping services check. when I get cygcheck to run to completion). So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. ~ Paul cygcheck-complete.out Description: Binary data -- 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
Re: cygutils Postinstall Script Errors With Exit Code 128
cygwin-owner at cygwin dot com wrote on 05/29/2013 11:47:20 AM: From: Reini Urban rurban at x-ray dot at To: The Cygwin Mailing List cygwin at cygwin dot com, Charles Wilson cygwin at cwilson dot fastmail dot fm, Date: 05/29/2013 11:47 AM Subject: Re: cygutils Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: snip Package: cygutils cygutils.sh exit code 127 Package: man man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database /usr/bin/update-mime-database /usr/share/mime snip -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ Those update-* files do not exist for me either. However, I think my problems are starting before cygutils.sh returns with exit code 127. Are you asking me to test that the files exist before I run them? Or, are you asking the Cygwin maintainers to have their cygutils script do so? ~ Paul -- 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
Re: Postinstall Script Errors With Exit Code 128
On 5/29/2013 3:18 PM, paul.nicker...@desknetinc.com wrote: cygwin-owner at cygwin dot com wrote on 05/29/2013 12:28:30 PM: From: Larry Hall (Cygwin) reply-to-list-only-lh at cygwin dot com To: cygwin at cygwin dot com, Date: 05/29/2013 12:29 PM Subject: Re: Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On 5/29/2013 12:04 PM, Paul.Nickerson wrote: snip I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. This list has seen the occasional question about AWS and Cygwin in the past but AFAIK, no one active on the list is using AWS with Cygwin. My best suggestion at this point is to consult the Amazon folks to get their input. The fact that cygcheck doesn't run to completion really points to an issue outside of Cygwin proper, since cygcheck is a vanilla Windows program. -- Larry I tried removing cygwin1.dll from the bin directory and re-running cygcheck.exe, and it ran to completion. When I ran it, I got the below popup and error, and I have attached the produced output, created with C:\cygwin\bincygcheck -s -v -r -h cygcheck.out 21. I got the error after the Path: and before SysDir:. --- id.exe - Unable To Locate Component --- This application has failed to start because cygwin1.dll was not found. Re-installing the application may fix this problem. --- OK --- garbled output from 'id' command - no uid= found Right. That's expected. Looking at cygcheck's source, it looks like after displaying Warning: cygwin1.dll not found on your path or Warning: There are multiple cygwin1.dlls on your path, it runs dump_dodgy_apps() (which gives no output when I get cygcheck to run through to completion), and then it runs dump_sysinfo_services() (which gives the output Can't find the cygrunsrv utility, skipping services check. when I get cygcheck to run to completion). So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. Possibly. You may have a BLODA problem (http://cygwin.com/acronyms/#BLODA), whether known or unknown. If so, getting rid of it will certainly help. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. Interesting. Maybe there's some Windows permission problems in the directory you were running from? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/29/2013 11:47 AM, Reini Urban wrote: I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database /usr/bin/update-mime-database /usr/share/mime Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... ...I'm waiting for Yaakov to say whether this should be fixed in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. [1] arguably, cygport is doing the right thing: (1) ensuring that the tools are called to install the two files, and (2) ensuring that the packages which contain those tools are listed in the requires: line. So, I'm not sure what the correct fix should be, and am waiting for Yaakov's input. See: http://cygwin.com/ml/cygwin/2013-05/msg00211.html -- Chuck -- 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
Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
Sorry for missing this before. On 2013-05-29 17:43, Charles Wilson wrote: Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. Right, because packages providing those kind of files usually need those commands to be run in order for them to take effect; see below. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... Perl? I thought it was Python, due to a false positive in the dependency detection with glib2.0, which I fixed on sourceware. But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. ...I'm waiting for Yaakov to say whether this should be fixed in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. The problem here is that cygutils is not primarily a desktop-oriented package. Most packages providing XDG menu and mime entries *are*, so these dependencies not only mandatory, but quite modest by those standards. I added these files because it allows better integration between desktop file managers (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it easy to launch an EXE/MSI installer from one's Downloads folder. However, most people use cygutils outside of the desktop, so particularly if its pulled into Base, these deps would be more than the bare-minimal system. If cygutils should be in Base, the solution is probably one of the following: * provide these files (and postinstall scripts) in a 'cygutils-x11' subpackage; * OR move them to another package (not sure which yet) which will already be installed in desktop scenarios, and adding cygutils as a dependency thereto. For now, should we go with the first option? Yaakov -- 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
Re: Postinstall Script Errors With Exit Code 128
On 5/28/2013 3:43 PM, paul.nicker...@desknetinc.com wrote: I am attempting to install Cygwin, and am getting errors near the end of the process. I am using version 2.774 of setup.exe on Microsoft Windows Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote desktopping in. In the Cygwin Setup GUI, after it goes through the install procedure, I get a window titled Postinstall script errors, with the below output text: Package: base-cygwin 000-cygwin-post-install.sh exit code 128 Package: terminfo terminfo.sh exit code 128 Package: bash bash.sh exit code 128 Package: coreutils coreutils.sh exit code 128 Package: _autorebase autorebase.bat exit code -1073741819 Package: base-files base-files-profile.sh exit code 2816 base-files-mketc.sh exit code 128 Package: cygutils cygutils.sh exit code 127 Package: man man.sh exit code 128 If I then open Cygwin Terminal using the Desktop shortcut, I get a window titled -sh and a prompt that says -sh-4.1$. The command ls returns -sh: ls: command not found, but echo works. I have tried re-running setup.exe, removing the cygwin directory, re-downloading the setup.exe, removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, setting Turn on DEP for essential Windows programs and services only and rebooting, altering file and folder permissions, deleting the cache and using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in Windows to remote desktop in, but none of this changes the behavior. I have an odd and possibly related behavior. If I open Command Prompt, run C:\cygwin\bin\bash.exe --norc --noprofile to get a bash-4.1$ prompt, then in there run if [ foo = foo ]; then echo Expression evaluated as true.; fi the bash prompt will exit back to command prompt, and %ERRORLEVEL% has been set to 128. Running that if statement in the window brought up by the Cygwin Terminal Desktop shortcut will sometimes make the window close, but not always. I have not explored how I might be triggering the Desktop shortcut to work or not work. I have attached setup.log and setup.log.full. When I run cygcheck -s -v -r cygcheck.out, it hangs and does not exit. Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual cores). It does write some things out to cygcheck.out, which I have attached. When I run the command in Command Prompt without redirecting output to a file, I get a little more information before it hangs, which I have copied out of the command prompt and attached as cygcheck-no-redirect.out. I do not know why it's saying I have multiple cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. Looking at cygcheck.out, I am running in a Terminal Service session, which makes sense as I am remote desktopped in. My problem might be related to FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts ), but the DEP solution is not helping me. I tried running C:\cygwin\binpeflags --tsaware=true --tsaware * in Command Prompt, but it did not change anything. Try removing GS and OpenVPN from you path and try installing again. If that doesn't work, you might try installing Just for Me. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
