Re: man.conf missing after cygwin upgrade (Attn: User's Guide maintainer)
On 7/7/05, Igor Pechtchanski wrote: If you still haven't run setup since that fateful man installation no, I didn't Good. The file was actually very helpful. Perhaps we could offer general advice in the User's Guide section on setup to back up that file in case of any installation problems. Done, see: http://cygwin.com/cygwin-ug-net/setup-net.html#internet-setup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: man.conf missing after cygwin upgrade (Attn: User's Guide maintainer)
On Sun, 10 Jul 2005, Joshua Daniel Franklin wrote: On 7/7/05, Igor Pechtchanski wrote: If you still haven't run setup since that fateful man installation no, I didn't Good. The file was actually very helpful. Perhaps we could offer general advice in the User's Guide section on setup to back up that file in case of any installation problems. Done, see: http://cygwin.com/cygwin-ug-net/setup-net.html#internet-setup Looks good, thanks. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: man.conf missing after cygwin upgrade (Attn: User's Guide maintainer)
On Thu, 7 Jul 2005, FischRon.external wrote: Please make sure your mailer respects the Reply-To: header -- I set it for a reason. There's no need to Cc: me on the messages, as I read the list. Thank you for pointing this out! It's done correct now. Yes it is. Thank you for noticing and correcting the problem -- you'd be surprised how many don't. On Tue, 5 Jul 2005, FischRon.external wrote: I found that all in a while, a file created under cygwin ends up with permission 000... This usually indicates wrong directory permissions on higher-level directories. Could you please post the output of getfacl /usr /usr/share /usr/share/misc (seeing as you've already posted the output of getfacl /). ~ $ getfacl /usr /usr/share /usr/share/misc # file: /usr # owner: Administrators # group: mkpasswd ^^^ user::rwx group::--- ^^ group:SYSTEM:rwx mask:rwx other:--- default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx # file: /usr/share # owner: Administrators # group: mkpasswd ^^^ user::rwx group::--- ^^ group:SYSTEM:rwx mask:rwx other:--- default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx # file: /usr/share/misc # owner: fischron # group: Users user::rwx group::rwx group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:rwx default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:rwx Looks correct, doesn't it? Well, the underlined lines above (those that say group: mkpasswd) do look problematic -- your /etc/passwd and /etc/group aren't up-to-date. I'd investigate what the actual group of those files is, and regenerate your mkpasswd (are you in a domain, by any chance?). The other underlined lines (group:---) may be a problem too, just because the directories are owned by a Windows *group*. It's also possible that the ownership by a group confuses directory permission inheritance, so that you end up with 000 permissions plus a couple of ACLs (that aren't picked up by Unix tools like stat/test). If you haven't run setup since upgrading man, see if /var/log/setup.log.full has any messages from /etc/postinstall/man.sh. Nothing useful. man.sh is mentioned only once: Installing file cygfile:///etc/postinstall/man.sh Very weird. So the postinstall script didn't run? The log file has a lot of lines saying Installing file . postinstall , but at the end, when it comes to actually running the postinstall files, I see in the log only the following: 2005/07/04 12:33:17 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/cron.sh 2005/07/04 12:33:19 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/cygwin-doc.sh 2005/07/04 12:33:19 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/d.sh 2005/07/04 12:33:20 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/emacs.sh 2005/07/04 12:33:25 mbox note: Installation Complete 2005/07/04 12:33:28 Ending cygwin install Just to mention a few, the following postinstall files were *not* run according to the log file: cygfile:///etc/postinstall/base-files-mketc.sh This one did, but didn't complete. cygfile:///etc/postinstall/man.sh cygfile:///etc/postinstall/pdksh.sh cygfile:///etc/postinstall/wget.sh cygfile:///etc/postinstall/update-info-dir.sh Yep, these didn't run. There are more in your postinstall directory below. and many, many more. I noticed that your log has many Scheduled reboot replacement lines -- you had Cygwin processes running while installing. I suspect the problem with postinstall scripts is that the emacs one popped up some Windows message boxes (e.g., Entrypoint... not found), and thus setup didn't run the others. Did setup recommend that you reboot? Did you? I've always though the on-reboot-replacement policy is annoying. This shows that it may be incorrect as well. Do you recommend that I run all the other postinstall scripts manually, like I did with man.sh? After a reboot, yes, I'd suggest running the scripts (you may even try reinstalling the affected packages via setup). See below for a list. The only thing which might look like an error message does not seem related to the man problem: 2005/07/04 12:27:54 zsh 2005/07/04 12:27:54 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/base-files-mketc.sh Unknown system type ; exiting That's even weirder. What does uname -a show? You should not get that message on Win2k Pro (as your previously attached cygcheck output indicates). CYGWIN_NT-5.0 mucw0291 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin Extremely weird. Could it be the same problem (some utility exited producing no output because of the wrong current versions of files)? You should re-run /etc/postinstall/man.sh.done I guess you mean: /etc/postinstall/man.sh - there is no file /etc/postinstall/man.sh.done No, I meant
RE: man.conf missing after cygwin upgrade (Attn: User's Guide maintainer)
~ $ getfacl /usr /usr/share /usr/share/misc # file: /usr # owner: Administrators # group: mkpasswd ^^^ user::rwx group::--- ^^ group:SYSTEM:rwx mask:rwx other:--- default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx # file: /usr/share # owner: Administrators # group: mkpasswd ^^^ user::rwx group::--- ^^ group:SYSTEM:rwx mask:rwx other:--- default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx Well, the underlined lines above (those that say group: mkpasswd) do look problematic -- your /etc/passwd and /etc/group aren't up-to-date. I'd investigate what the actual group of those files is, and regenerate your mkpasswd (are you in a domain, by any chance?). Yes, I am. I have just recently (i.e. after the setup) re-created both /etc/group and /etc/passwd. With /etc/group, I did a mkgroup -l -d /etc/group not nowing that this would really scan all my domain, so after more than half an hour, I'm ending with a /etc/group file containing nearly 3 lines. With mkpasswd, I then made only a mkpasswd /etc/passwd Incidentally, a group named mkpasswd does not exist. Do you think I should do a chgrp to all directories below / which now have group mkpasswd? What group would be suitable? Maybe Administrators? $ mkgroup -l SYSTEM:S-1-5-18:18: None:S-1-5-21-602162358-162531612-725345543-513:513: Administrators:S-1-5-32-544:544: Backup Operators:S-1-5-32-551:551: Guests:S-1-5-32-546:546: Power Users:S-1-5-32-547:547: Replicator:S-1-5-32-552:552: Users:S-1-5-32-545:545: Debugger Users:S-1-5-21-602162358-162531612-725345543-1001:1001: The other underlined lines (group:---) may be a problem too, just because the directories are owned by a Windows *group*. OK, I have chmod'ed this to 0777. It's also possible that the ownership by a group confuses directory permission inheritance, so that you end up with 000 permissions plus a couple of ACLs (that aren't picked up by Unix tools like stat/test). This makes sense to me. I didn't know that permissions are inherited from the parent directory. Is this a Windoze feature? Just to mention a few, the following postinstall files were *not* run according to the log file: cygfile:///etc/postinstall/base-files-mketc.sh This one did, but didn't complete. But shouldn't then in the logfile be an entry running postinstall/base-files-mketc.sh ? cygfile:///etc/postinstall/man.sh cygfile:///etc/postinstall/pdksh.sh cygfile:///etc/postinstall/wget.sh cygfile:///etc/postinstall/update-info-dir.sh Yep, these didn't run. There are more in your postinstall directory below. You mean: All where a sh file, but no corresponding done file is in the postinstall directory? I noticed that your log has many Scheduled reboot replacement lines -- you had Cygwin processes running while installing. Yes, this is correct. I have always some bash shells open. But after the setup was finished (and I didn't get any error message from the setup script), I restarted the system. One bash file is opened by Windows autostart. Could this interfere with the post-install? I suspect the problem with postinstall scripts is that the emacs one popped up some Windows message boxes (e.g., Entrypoint... not found), and thus setup didn't run the others. Did setup recommend that you reboot? Yes Did you? Yes Do you recommend that I run all the other postinstall scripts manually, like I did with man.sh? After a reboot, yes, I'd suggest running the scripts (you may even try reinstalling the affected packages via setup). See below for a list. Yes, I think re-running setup is the cleanest solution. I will do this next week and keep my experiences posted. That's even weirder. What does uname -a show? You should not get that message on Win2k Pro (as your previously attached cygcheck output indicates). CYGWIN_NT-5.0 mucw0291 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin Extremely weird. Why? According to the man page, the only unknown entries relate to the parameters processor and hardware-platform, and it is easy to imagine that uname can't extract that information. Could it be the same problem (some utility exited producing no output because of the wrong current versions of files)? I don't understand: How could this affect uname? Ok, so you need to run all the ones that end in .sh, and rename them to .done (while overwriting the old versions). If you make a note of which scripts need running, and set those packages to Reinstall in setup, setup will do this for you. OK, but wouldn't it be easier to simply have setup to update them automatically? This is an interesting problem, thanks for helping debug this. Thank you for helping me to get it running! Ronald -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem
