Can you try to change /etc/security/console.perms.d/50-default.users line:
<console>  0600 <sound>      0660 root.audio

to
<console>  0600 <sound>      0660 root

Does it help?

What does getent group audio print?

before applying the change, `getent group audio` returns nothing
after applying the change, `getent group audio` returns nothing.

yes, applying that change certainly fixes it.


Regards,
Andrew

It looks like that for some reason the %post script in the pam package which is supposed to add that group to the system did not run correctly.

As this needs to be investigated more in depth can you please log in to Red Hat Support for assistance with your issue and so that your issue can be resolved in a prompt and timely manner. 

Please mention this bug number in the support request.

I apologize if I'm not doing this correctly - not sure if I need to create a new bug report and/or if I can annotate this bug report.

Product: Red hat Enterprise Linux 5
Version: 5.5
Platform: x86_64
Component version:  pam-0.99.6.2-6.el5_4.1

Description:  udev hangs after upgrade to el5.5

The system hangs for several minutes until udev times out with the following error message:  "Starting udev: Wait timeout. Will continue in the background [FAILED]"

Booted the system utilizing the "udevdebug" option to grub and received the following error messages:  "udevd-event [###]: run_program: Waiting ## seconds for output of '/sbin/pam_console_apply /dev/..." 

Steps to reproduce:

1.) Install el5.3 or el5.4
2.) Upgrade to el5.5
3.) Reboot system.

Resolution per stated above:

Modifying the /etc/security/console.perms.d/50-default.perms as show below resolves the problem.  Additionally, “getent group audio” returns nothing before and after the change.  Adding the group which exists and/or is created during the fresh install also resolves the problem, “audio:x:63:gdm”.

<console>  0600 <sound>      0660 root.audio

to

<console>  0600 <sound>      0660 root


NOTE: This problem is not encountered with a fresh install, i.e. blow away install.  In contrast, “getent group audio” returns “audio:x:63:gdm” on a fresh install.  Also the /etc/security/console.perms.d/50-default.perms file contains “<console> 0600 <sound> 0660 root.audio”.

Thanks.

Also, another piece to this puzzle. I kickstart all my servers from a fairly minimal base group, so it may be that whatever is supposed to be creating the audio group is not installed. Then PAM does not check that this is so, before it upgrades assuming it is. Certainly no audio related programs are installed as these are production servers, not workstations, and as such do not require any form of audio.

Either way, the audio group does not exist at the time of the pam update, and does not afterward either.

Regards,
Andrew.

But pam adds the group explicitly with:
getent group audio >/dev/null || \
    /usr/sbin/groupadd -g 63 audio 2>/dev/null || :

in its %post.

Do you see /etc/group- file with the group audio in it on the machine that does not contain the group in the /etc/group file?

[root@cassia etc]# grep audio group-
[root@cassia etc]# 

niet :(

Andrew.

> But pam adds the group explicitly with:
> getent group audio >/dev/null || \
>     /usr/sbin/groupadd -g 63 audio 2>/dev/null || :

Seems the returned value of getent might not be what is expected.

   # grep audio /etc/group
   # grep audio /etc/group-
   # getent group audio
   # echo $?
   2

So the group would not be added in %post in that case, would it?

No, it would - || means execute the following command on non-zero exit status of the previous command.

I've tried updating a RHEL-5.3 install to RHEL-5.5 and the %post script worked correctly and added the group to the /etc/group. So I have to say, that I cannot reproduce the problem.

The problem centers around - GID 63 already existing.

We use LDAP.  Group ID 63 already exists and is widely used throughout the organization.  Most all users are a part of this group, even utilizing this as their default group.

The post install for pam fails to add the group as shown below without the redirection to /dev/null.

# getent group audio >/dev/null || \
>     /usr/sbin/groupadd -g 63 audio || :
groupadd: GID 63 is not unique
#

OK, great, that then makes sense.

We can modify the script so it adds the group audio without specifying the group id in case a group with gid=63 already exists.

if ! getent group audio >/dev/null ; then
    if getent group 63 >/dev/null ; then
         /usr/sbin/groupadd -r audio || :
    else
         /usr/sbin/groupadd -g 63 audio || :
    fi
fi

well, now I feel stupid, same for me ... sigh

objectClass: posixGroup
objectClass: top
cn: XXXX
gidNumber: 63
memberUid: xxxxx
memberUid: xxxxy
memberUid: xxxxz

( only the names have been changed to protect the innocent ... )

Andrew.

Tomas - et al,

Not sure if this is the correct place to discuss this but, I guess you can argue that this is really not a bug.  Basically, we shouldn’t be using group IDs below 500.

With the fix provided, what are the implications of having inconsistent GIDs for the audio group across system builds?  Does this even matter from an OS perspective?  At the other end of the spectrum, what are the implications of no audio group, and removing audio from the sound entry in /etc/security/console.perms.d/50-default.perms file? The latter of course being used by our organization until we can address and resolve our group ID dilemma.

Thanks.

You shouldn't be using group IDs below 100. The range between 100 and 500 is dynamically added system groups so this range might be used for special purposes such as third party software or so. The groups in this range are not added with exact group id.

I can't really come up with any serious problem caused by dynamically allocating the gid for the audio group as the only user in the distribution is the gdm and the 50-default.perms in pam and both of these users are referencing it just by the name and not the gid.

Of course you can also remove the audio from the 50-default.perms as a workaround and it would just remove the accessibility support (text reader) from gdm. However the 50-default.perms file is not a 'noreplace' %config file so in case of pam update your change would be overwritten.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Closing this as a notabug given the updates here and that there is a valid way to avoid this problem.  If you disagree with the closure of this BZ please open a support case with Red Hat at access.redhat.com.