I run cygwin under Windows 10 on a laptop that was purchased and configured several years ago and has worked fine, more or less, ever since. Until today.
I hadn’t rebooted for several weeks. Sometimes Windows tells me it wants to Update but I just click “Remind me Later.” This morning the machine rebooted itself — perhaps it gave me the chance for the “Remind me Later” click and I missed it. I’ve noticed two changes: (1) The “Activate Windows” message at screen’s lower right is now gone. (2) The start-ups of ‘xterm’ fail.
From the error message, I’ll guess a cygwin binary is incompatible with a new Windows binary, and downloading a few cygwin .dll’s might be all that’s needed. But I barely know what a .dll is. I know there are some Cygwin experts here. Please give me some idea of how to proceed! Treat me as an utter novice.
The Xserver(?) presents a new window when I type ‘startx’, but after about one second that window disappears. I show the error messages below. Given how I use this laptop, running without my xterms will be like operating with one hand tied behind my back.
The ‘startx’ transfers control to ‘~/.xinitrc’ whose contents I’ll PM to anyone who needs them but that file is time-stamped Sep 4 2013 so has worked adequately for quite a while. (The " XFree86_VT property unexpectedly has 0 …" message has been around the whole time but never caused obvious trouble so I never worried about it. :smack: )
Here is what I see on my cygwin console:
% startx
xinit: XFree86_VT property unexpectedly has 0 items instead of 1
2 [main] xterm 1776 child_info_fork::abort: D:\cygwin\bin\cygbz2-1.dll: Loaded to different address: parent(0x4B0000) != child(0x2C0000)
xterm: Error 29, errno 11: Resource temporarily unavailable
Reason: spawn: fork() failed
[these three lines are repeated four times]
xinit: connection to X server lost
waiting for X server to shut down
% ls -l /cygdrive/d/cygwin/bin/cygbz2-1.dll
-rwxr-xr-x 1 acer None 62990 May 22 2011 /cygdrive/d/cygwin/bin/cygbz2-1.dll
%
No. And please treat me like an utterly ignorant novice. Should I download a new setup-x86_32.exe or hunt for the one I downloaded several years ago? Will the setup program automatically do what needs to be done, or will I have to tell it what to do? I could treat it as install-from-scratch, I guess — that seems “scary” to me, but is that best? What if I just download the specific file (cygbz2-1.dll) it complains about?
If you’re currently running a 32-bit cygwin, then just download setup-x86.exe and run it. It should remember what packages you have installed, so you just have to click Next on each of the screens until it finishes. I would not try to install individual files piecemeal; that’s much more likely to break things than letting the installer do it. It’s really pretty foolproof.
OK. I’ve downloaded and clicked setup and, after a false start or two, it is now downloading cygwin packages (the default “necessary” updates?). This will take many minutes. Let’s cross our fingers.
It may seem strange I’m such a “nervous Nellie.” Once upon a time I almost literally took soldering irons to million-dollar mainframes, with confidence and success. Compared with my present feelings of incompetence and inadequacy sometimes it’s hard for me to believe I’m the same person as before! :smack:
Some packages are dependent on other packages. So you may get package X that you didn’t ask for because package Y that you did ask for it depends on package X. I would just let it finish.
It’s done its “removes” so it’s too late to cancel, and is now 39% of “setup.”
(As a matter of philosophy, since I was perfectly satisfied with my cygwin environment, except for this sudden xterm glitch after 5+ years, is it really appropriate that it inflicts an update on me involving thousands of files? I would have happily chosen a ‘don’t use shared libraries’ option to avoid even the xterm glitch, but AFAIK there’s no such option.)
As I expected, once I understand that it was doing a complete re-install, at least two minor problems have already surfaced:
(1) IIRC my previous cygwin had no usable ‘vi’ except ‘vim.’ Now it has a ‘vi’ which appears to behave like the old ‘vim’ and a ‘vim’ which malfunctions, possibly ignoring my .vimrc. I wouldn’t have noticed this except I had ‘alias vi vim.’ I have some scripts that invoke ‘vim -s’ – will see if they still work.
(2) I found the old ‘su’ (switchuser) command convenient, even though it couldn’t actrually change Windows user. It allowed me to have multiple “users” in the /etc/passwd with the same user id. ‘su’ had been dropped from cygwin more than 5 years ago, but I copied an su.exe binary from an even older cygwin and it worked! I forgot to make a copy of that su.exe, and the setup apparently wiped out the entire binary directory. Maybe I’ll try powering on an old old laptop just to grab its su.exe !
I can’t really offer any specific insight as to what went wrong with the old install, only a general comment. By not updating the Cygwin installation for years but updating the operating system it’s running on*, you’re basically running the environment on a moving target. The things it used to depend on are probably gone or are living somewhere else in the operating system under a [DEL]witness[/DEL] service protection program under a new identity. The later releases noticed these problems and adjusted their code accordingly.
Re-running the setup command updates the system to the latest version. As was mentioned before, the system was grabbing the other files due to the dependencies of the updated packages.
If you manually copied su.exe to the system that recently cracked up, then the installer in that version didn’t know about it, and couldn’t update it**. According to this version of the Cygwin faq, su has been in+out of the distro, but it can currently be installed with the sh-utils package. It apparently doesn’t work as someone from a unix environment would expect it to work, but you already knew that.
As another person who uses Cygwin on a Windows machine for work these days, can I ask a question? Why aren’t we using WSL? The only excuse I can come up with is inertia. I’m actually considering running Linux in a VM at work for these tasks rather than using WSL, and I know that’s just because I know Linux better than WSL.
*And if you haven’t updated your Windows box in five years, back up your data and reinstall, you’re almost surely owned by something. I’d back up my data and burn the computer in the yard if I realized I had done that, but that’s just me.
**Yeah, wiping /bin is a pretty douche-y thing to do. I don’t have any defense for that other than: Forget it, septimus - It’s Cygwin town. In the future, manually install binaries in ~home/bin/, and add that to your path. Anyone that wipes files from there shouldn’t be allowed on your computer.
Heh, missed the edit window, but make that “~/bin” or /cygwin/c/home/<user>/bin/
And I also realize this would be dumb advice on a real unix system. It would probably not be in the path of other users and /usr/local/bin/ would be the right place to put it. But since this was Cygwin and it doesn’t actually change the user, it should work just fine. Plus, I was being too lazy to verify where /usr/local/bin/ would be in Cygwin, even if it was /cygwin/c/usr/local/bin/ .
ETA: Heh, didn’t miss the edit window. God, I’m drunk. I’d delete the correction, but I’ll leave it here to edify those of the pitfalls of providing tech support while in this state while not double checking anything. There’s errors all over them.
The functionality I need in ‘su.exe’ is probably about 3 lines of C. But I don’t know what those three lines are. I guess I can get the source via cygwin’s setup :smack: , but I’ve no appetite to repeat that horror show. I could ‘git’ it I guess, but I think it would take me hours to figure out how to make ‘git’ git what I want. What happened to Browse and Save? Too user-friendly?
If you don’t update for years and then do an update, it doesn’t seem surprising that a lot of things get updated. Now that you’re up to date, if you run setup again and don’t select any new packages, it will do almost nothing. If you select one new package (sh-utils), it will just install that one package, and should be very fast. I agree that wiping /bin kind of sucks, but in the future if you install programs “behind the back” of cygwin (not via the installer), you should install them in ~/bin rather than a system directory, to ensure that cygwin doesn’t mess with them.
Fortunately the peculiar way I was using ‘su’ has an easy work-around. The behavior of ‘vi’ seems close enough to the old ‘vim’ (when set to ‘vi’ compatibility mode) that I shouldn’t have trouble. One of the biggest known “problems” right now is a new format of ‘gcc’ error messages but I don’t think I’ll get much sympathy protesting that!
I do notice that a trivial C program now compiles to a 150k binary instead of 50k. And ‘vi’ seems sluggish, at least at start-up. But ever-growing bloat has been the norm for decades, no?
Thanks for giving me the confidence to run ‘setup’! It seemed very scary (and was!) but was probably the most straightforward solution.
On the old cygwin, a pure-compute process on my dual-core got 9% of the CPU, but if I start 3 instances of the process, they each got 30%. :eek: I’ve not yet checked to see whether that problem has gone away.
