On Aug 14, Marco d'Itri [EMAIL PROTECTED] wrote:
Stack traces are generated with the bt command of gdb, and they need to
be from an unstripped binary to be useful.
Do you still believe that udevstart is crashing?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Aug 21, 2005 at 11:17, Marco d'Itri praised the llamas by saying:
On Aug 14, Marco d'Itri [EMAIL PROTECTED] wrote:
Stack traces are generated with the bt command of gdb, and they need to
be from an unstripped binary to be useful.
Do you still believe that udevstart is crashing?
Yes
Package: udev
Version: 0.056-3
Severity: important
udev should create groups that udev relies on for permissions during the
postinst. For example permissions.rules tries to change the group of
/dev/nvram to nvram, but this group does't necessarily exist on a
system. As a result, udevstart exits
On Aug 14, [EMAIL PROTECTED] wrote:
system. As a result, udevstart exits before it has completely populated
/dev/ during startup.
What makes you believe this? Look at lookup_group() in
udev_libc_wrapper.c, the function never fails:
gid_t lookup_group(const char *group)
{
struct group
On Aug 14, 2005 at 11:04, Marco d'Itri praised the llamas by saying:
On Aug 14, [EMAIL PROTECTED] wrote:
system. As a result, udevstart exits before it has completely populated
/dev/ during startup.
What makes you believe this? Look at lookup_group() in
udev_libc_wrapper.c, the function
On Aug 14, David Pashley [EMAIL PROTECTED] wrote:
Extensive debugging. udevstart crashed trying to look up the group.
Creating the nvram system group fixed it. It's entirely possible that
the crash is due to libnss-ldap, but that doesn't change the fact that
you are relying in a group which
On Aug 14, David Pashley [EMAIL PROTECTED] wrote:
If udevstart is actually crashing (something which I doubt), please get
a stack trace.
Is it not wise and pratical to add the groups that you, yourself list in
the packaged version of permission.rules?
Yes.
strace attached.
This is not a
7 matches
Mail list logo
