Red Hat Bugzilla – Bug 158662
Installer exits when probing disks if 8TB LUN visible on system
Last modified: 2008-02-13 17:52:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Red Hat/1.0.3-1.4.1 Firefox/1.0.3
Description of problem:
When an 8TB LUN is advertised to a RHEL4 AS U1 beta (0421.0 build) system, the installer will exit and leave the user at a "You may now reboot your computer" type message after probing for storage devices. The LUN for this test was created on a NetApp NearStore R200. The test computer was an HP DL380. The FC adapter in the RHEL system was a dual-port Qlogic 2312.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up an 8TB LUN on storage device, advertise LUN to RHEL system
2. Begin install
3. Proceed through install to point where storage is probed
Actual Results: Installer exits and waits for me to reboot.
Expected Results: Normal installation with disk druid able to see 8TB LUN or normal installation with LUN not visible to disk druid.
RHEL could be installed and would function normally when the LUN was not visible. If the LUN was set up after installation, the system could successfully mount a filesystem created on the LUN and could be rebooted without incident.
During the install sequence, if I went to a shell prompt before the installer reached the storage section, I could use "fdisk -l" and see the LUN. However, when the installer reached the storage section it would exit.
Just exits abnormally with no other text? Can you grab both /tmp/syslog and
/tmp/anaconda.log from the shell.
Also, what happens if you just run parted /dev/sda from the installer shell?
Unfortunately I can't perform any additional testing as I was offsite at NetApp
when I discovered the issue. The installer just exited, leaving me at a screen
with multiple lintes of text that ended with
"you may safely reboot your system"
I'm sorry I can't be more specific than that, but I only ran the test as an
afterthought as I was leaving to come back to RH. I didn't copy down the exact
text, but I was able to repeat the problem in both text and GUI installs.
Do we have any way to replicate the problem in-house?
> Do we have any way to replicate the problem in-house?
Yes, I will reproduce this in Westford.
Did this get resolved for U3?
Tom - were you ever able to reproduce this problem, especially on later update
Please test this on the Winchester in the lab. I'd suggest RHEL 4 U4. Try a
32-bit system and a 64-bit system.
I just reproduced this on p750.lab (32-bit). I had the exact same behavior using
RHEL4 U4 as reported. I'm trying to locate a 64-bit system that I can test this
I just tried to reproduce this crash on a 64-bit system (hammer7.lab), and it
did not have the same issue. It reported that there was a GPT partition table,
but there was something wrong with the fake standard partition table (which is
entirely possible, I'm not sure what's actually on the disk). This is the same
drive that caused the 32-bit installer to fail, and it passed on 64-bit.
Can someone test with 4.5 and see if it's still present? If not, I'd like to
perform an install using this storage system. I have an idea as to what's
happening, but I need a shell to debug it.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
do we have a reproducer for that? Automation is desired if possible.
I set up the same system as comment 8 and tried RHEL 4.6.
The storage device happens to be > 8TB for this test:
SCSI device sdc: 23385821184 512-byte hdwr sectors (11973540 MB)
sda and sdb are normal sized IDE drives.
The installer discovered all the storage properly. I selected "automatic
partitioning" and "remove all partitions on all disks". The "Disk Setup" page
came up and showed the proposal for partitions and LVM configuration. For the
big disk, it showed:
8388605 MB sdc1
3030253 MB free
and for the root LV:
VolGroup00 8865184 MB
LogVol00 / ext3 8.85936e+06 MB
So it appears to be respecting the 8GB limit in RHEL 4 x86 (I did not check the
When I completed the dialog and the install started, it failed right away with a
window saying "An error occurred formatting VolGroup00/LogVol00. The problem is
ctrl-alt-F5 shows "mke2fs: Filesystem too large. No more than 2**31-1blocks...".
So it appears that Anaconda's attempt to trim the big disk didn't quite work.
(It would be nice to have a more informative message in the GUI error message.)
This looks different from the original problem. I can retry with exactly 8GB if
you like. This system does not have very good remote access or automation,
unfortunately. If there is better system in the Westford lab for you to debug on
I can probably attach the storage to it.
Original problem reported appears to be working per comment #13, closing this bug.