Mail Archives: cygwin/2005/07/07/11:34:51
On Thu, 7 Jul 2005, FischRon.external wrote:
> > > ~ $ 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 30000
> lines. With mkpasswd, I then made only a
>
> mkpasswd >/etc/passwd
The -u flag to mkpasswd (and -g flag to mkgroup) are your friends. See
the User's Guide.
The thing is that if you're the only user in your domain using the
machine, you can simply run "mkpasswd -l -c > /etc/passwd" (or "mkpasswd
-l -d -u YOURUSERNAME > /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?
Just bring your /etc/passwd and /etc/group files up-to-date. See
<http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-ids>.
> $ 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.
I think your main problem wasn't with permissions, but with postinstall
scripts not running properly. See if running them fixes the problem.
> > 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?
Yes, but again, do the postinstall thing first, and see if permissions
matter afterwards.
> > > 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" ?
There was. It's the one that said "Unknown system type ; exiting".
> > > 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?
All where there is a .sh file. The .sh file is run, and then renamed to
.sh.done by setup. The .sh.done files where there's also a .sh file are
old versions of the scripts. You probably want to run the new ones.
> > 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.
The "no error message" is a problem. FWIW, I'm working on one way of
fixing it, but don't know when that's going to be in.
> One bash file is opened by Windows autostart. Could this interfere with
> the post-install?
You mean autostart after reboot? No, it shouldn't -- Cygwin setup doesn't
run anything after reboot, it only uses Windows mechanisms for replacing
files...
> > 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.
Great.
> > > > 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.
Sorry, I was unclear here. It's not the output of "uname -a" that's
extremely weird, it's the fact that base-files-mketc.sh failed to extract
the system name -- it looks for CYGWIN_NT*. As I said, I suspect uname
didn't complete properly, and so the output that the script got was empty.
> > 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?
Uname is linked with the new version of cygwin1.dll, which may have added
system calls. If the new uname looks for those system call entrypoints in
the old DLL, it won't find them, and will not complete properly, giving no
output. The script checks the output of uname, and of course will not
match it against any of the expected values.
> > 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?
Update them in what sense? The ones with .sh are the *new* versions.
The ones with .done are old ones, left over from the previous
installation. If you "Reinstall" the packages, setup will run every
<pkg>.sh script, and rename it to <pkg>.sh.done (automatically).
> > This is an interesting problem, thanks for helping debug this.
>
> Thank you for helping me to get it running!
No problem -- enjoy. :-)
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
--
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/
- Raw text -