RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

Choosing basic storage media for installation causes the graphical install to hang. The console-based installer also hangs at this step.

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

Red Hat Enterprise Linux 6 Beta

How reproducible:

100% reproducible

Steps to Reproduce:
1. Just select "Basic Storage Media" as the location to install.
2.
3.
  
Actual results:

Locks up.

Expected results:

Should take me to the screen where I can partition the drive.

Additional info:

Hardware involved:

1x 1.5 TB Samsung HD154UI ATA hard drive (Serial ATA, standalone, with Win7 Ultimate x64 installed)

1 RAID 10 array (unformatted):
 - 3Ware 9650SE SATA RAID Controller w/battery backed-up cache 
   - Model 9650SE-4LPML
   - Firmware FE9X 4.10.00.007
   - Driver 3.00.04.070
   - BIOS BE9X 4.08.00.002
   - BL9X 3.08.00.001
   - Available Memory 224 MB
 - 3x Samsung HD501LJ 465.76 GiB (500 GB) SATA II hard drives
   - Firmware CR100-13
 - 1x ST3500630AS 465.76 GiB (500 GB) SATA I hard drive
   - Firmware 3.AAK

Motherboard: ASUS M3A32-MVP Deluxe With WIFI
Processor: AMD Phenom 9600 Quad Core 2.3 GHz CPU
RAM: 8 GB OCZ Platinum
Video Card: Radeon HD 3850

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

This seems to be related to udevadm. Running top shows both top and udevadm using .3% CPU. After killing udevadm, the installer moves on to the next screen asking me to choose a disk. After selecting the RAID array and clicking next, it says "Finding Storage Devices..." and then sits there hung again. Top shows udevadm at .3% CPU again. Killing it several more times does not seem to help.

udev does not call udevadm. assigning back to anaconda.

Well that's not really true.  At least grepping /lib/udev shows 'udevadm'.

At any rate, anaconda runs 'udevadm settle --timeout=300'.  If udevadm is failing, there's nothing anaconda can do about it except reassign the issue to the owner of udevadm, which is the udev component.

It's probably worth having more log output.  dmesg output, log files in /tmp, etc?