Mail Archives: cygwin/2005/07/07/10:04:08
> > ~ $ 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
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 reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -