Bug 525353 - udev hangs on boot.
Summary: udev hangs on boot.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam
Version: 5.4
Hardware: i386
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-24 02:48 UTC by Andrew
Modified: 2011-10-17 02:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-17 02:04:00 UTC


Attachments (Terms of Use)

Description Andrew 2009-09-24 02:48:04 UTC
Description of problem:


Version-Release number of selected component (if applicable):
pam-0.99.6.2-6

How reproducible: 100% on my systems.


Steps to Reproduce:
1. install el5.3 release standard machine
2. upgrade to el5.4 specifically pam-0.99.6.2-6 from pam-0.99.6.2-4
3. reboot machine.
  
Actual results:
udev hangs for upto 4-5 minutes, then times out and boot continues without udev loading.

Expected results:
udev [OK]


Additional info:
reproduced using at least two different kernels
kernel-xen-2.6.18-164.el5 (citrix xen on blades)
kernel-PAE-2.6.18-164.el5 (standalone server on Dell Hardware)

Fix is to roll back pam package to earlier version.

Andrew.

Comment 1 Tomas Mraz 2009-09-24 06:37:53 UTC
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?

Comment 2 Andrew 2009-09-24 07:06:14 UTC
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

Comment 3 Tomas Mraz 2009-09-24 07:37:39 UTC
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.

Comment 6 John Bury 2010-05-11 16:44:41 UTC
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.

Comment 7 Andrew 2010-05-12 00:26:32 UTC
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.

Comment 8 Tomas Mraz 2010-05-12 06:48:02 UTC
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?

Comment 9 Andrew 2010-05-12 07:17:45 UTC
[root@cassia etc]# grep audio group-
[root@cassia etc]# 

niet :(

Andrew.

Comment 10 Olivier Fourdan 2010-05-12 07:36:29 UTC
> 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?

Comment 11 Tomas Mraz 2010-05-12 07:43:26 UTC
No, it would - || means execute the following command on non-zero exit status of the previous command.

Comment 14 Tomas Mraz 2010-05-12 09:14:14 UTC
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.

Comment 15 John Bury 2010-05-12 15:13:30 UTC
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
#

Comment 16 Tomas Mraz 2010-05-12 15:27:53 UTC
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

Comment 17 Andrew 2010-05-12 17:04:43 UTC
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.

Comment 18 John Bury 2010-05-12 18:06:32 UTC
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.

Comment 19 Tomas Mraz 2010-05-12 18:23:34 UTC
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.

Comment 22 RHEL Product and Program Management 2010-08-09 18:13:03 UTC
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.

Comment 24 RHEL Product and Program Management 2011-01-11 20:03:43 UTC
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.

Comment 25 RHEL Product and Program Management 2011-01-11 23:18:26 UTC
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.

Comment 26 RHEL Product and Program Management 2011-05-31 13:12:51 UTC
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.

Comment 27 David Mair 2011-10-17 02:04:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.