Bug 735261
Summary: | Anaconda doesn't support installation on host with 160 disks ( 20 LUN via 8 paths) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gris Ge <fge> | ||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | akozumpl, anaconda-maint-list, dlehman, g.kaviyarasu, jonathan, qcai, vanmeeuwen+fedora | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-03-17 19:51:34 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 756082 | ||||||
Attachments: |
|
Description
Gris Ge
2011-09-02 03:16:23 UTC
Please attach /tmp/*log. Ales, I tried sshd kernel option, but still no change to got a shell for it. Will the syslog=<IP> options provide sufficient information? Please switch to tty2, cd into /tmp and then copy out all the *log files there (using scp for instance). no ttys2 for beaker console. I will try KVM and provide the info to you. ok thanks. I'll keep this in needinfo until then. Created attachment 521561 [details]
Anaconda log for installation failure on storageqe-03
Storageqe-04 is busy with HBA driver auto-testing.
This is the log for storageqe-03, it only have 50 LUNs via 4 paths. (200 disks).
Not sure why we got many I/O error (maybe the LVM try to access the passive link).
I found 3 issue:
1. There will be 380+ LVM PVS process sanning each patition.
2. storage log show that you are try to scan multipath on /dev/sda1, it might be incorrect, multipath is not base on partition. for sda1, kpartx will handle it after mpath created.
3. syslog and other logs show that it suddenly been killed as the last log line only is partial.
My wild guess it's out of memory.
The syslog is full of errors like this: 22:14:12,133 ERR kernel:end_request: I/O error, dev sdcr, sector 4063216 22:14:12,133 INFO kernel:sd 4:0:1:46: [sdcr] Unhandled error code 22:14:12,133 INFO kernel:sd 4:0:1:46: [sdcr] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK 22:14:12,133 INFO kernel:sd 4:0:1:46: [sdcr] CDB: Read(10): 28 00 00 00 08 08 00 00 08 00 I think it is either a hardware error or some kernel problem. I don't think that is storage array hardware issue. And storageqe-03 and -04 are using different storage array. It's a little possibility that they are having problem at the same time. HBA driver testing show both storage array works well. I will investigate on these I/O errors' but I think you might need to find a good way for LVM PVS scan. I think kicking off large mount of lvm pvs process is what this bug supposed to fix. LVM should not touch any /dev/sdX before multipath started because accessing passive link will cause storage array performing controller transition. (That might why the I/O come). Customer will get angry if their storage array keep bouncing if you are access all link (passive and active). This is anaconda or initramfs issue. Change back to anaconda component. clearing the needinfo. This one has been skipped through several update releases, moving it over to rawhide so we can address it upstream and consider backports to RHEL releases after that. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Is anyone able to test this with F18 or F19-Beta-TC3? There has been a considerable amount of change in the storage since F13. |