Red Hat Bugzilla – Bug 606115
Scanning for Drives Locks Up
Last modified: 2010-06-28 17:34:06 EDT
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
Steps to Reproduce:
1. Just select "Basic Storage Media" as the location to install.
Should take me to the screen where I can partition the drive.
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
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?