Bug 158662
Summary: | Installer exits when probing disks if 8TB LUN visible on system | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Gary Case <gcase> |
Component: | parted | Assignee: | David Cantrell <dcantrell> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | bdonahue, coughlan, rkenna |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHEL-4.6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-02-13 22:52:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gary Case
2005-05-24 17:22:59 UTC
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 releases? Ryan, 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. Tom 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 on next. 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 release. Tom, Ryan, do we have a reproducer for that? Automation is desired if possible. Thanks. 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 numbers). 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 serious. Reboot...". 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. |