Bug 1110147
Summary: | IOError: [Errno 9] Bad file descriptor | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | William Brown <william> | ||||||||||||||||||||||||||
Component: | python | Assignee: | Bohuslav "Slavek" Kabrda <bkabrda> | ||||||||||||||||||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||||
Version: | 20 | CC: | bcl, bkabrda, dmalcolm, g.kaviyarasu, ivazqueznet, jonathan, jonathansteffan, mstuchli, tomspur, tradej, vanmeeuwen+fedora, william | ||||||||||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||||
Whiteboard: | abrt_hash:321bb09025685db23cf26aa5aa92e1f9ad94a25061f9b9124e5081be3f103e50 | ||||||||||||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||||||
Last Closed: | 2014-10-09 16:00:46 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: | |||||||||||||||||||||||||||||
Attachments: |
|
Description
William Brown
2014-06-17 06:57:01 UTC
Created attachment 909412 [details]
File: anaconda-tb
Created attachment 909413 [details]
File: anaconda.log
Created attachment 909414 [details]
File: environ
Created attachment 909415 [details]
File: ks.cfg
Created attachment 909416 [details]
File: lsblk_output
Created attachment 909417 [details]
File: nmcli_dev_list
Created attachment 909418 [details]
File: os_info
Created attachment 909419 [details]
File: program.log
Created attachment 909420 [details]
File: storage.log
Created attachment 909421 [details]
File: syslog
Created attachment 909422 [details]
File: ifcfg.log
Created attachment 909423 [details]
File: packaging.log
Somehow the stdout object vanished, possibly a python bug. Is this reproducible? Yes: The kickstart attached will always cause this issue to occur. i have a similar issue in rawhide also. I think this may be caused by bug 1103450 - Python attempts to close subprocess pipes twice when the child process starts failing. I'll try to backport patch for that bug to F20 and we'll see if that solves the issue. Otherwise I'll continue investigating. That may fix the bad file descriptor issue (Which is always good to fix more things) but the root of the cause is partitioning. See: zerombr clearpart --all --drives=sda clearpart --initlabel --drives=sda # Disk partitioning information part /boot --fstype=xfs --size=1024 --asprimary part pv.2 --size=16384 --grow --asprimary # LVM volgroup vg00 pv.2 logvol / --fstype=xfs --size=2048 --name=root_lv --vgname=vg00 logvol /usr --fstype=xfs --size=4096 --name=usr_lv --vgname=vg00 logvol /var --fstype=xfs --size=4096 --name=var_lv --vgname=vg00 logvol /home --fstype=xfs --size=2048 --name=home_lv --vgname=vg00 logvol swap --fstype=swap --size=2048 --name=swap_lv --vgname=vg00 However, looking at the storage log only /boot, home_lv and swap_lv are created. Is there an issue where anaconda can't kickstart with more than 2 lvs defined? IMO this is not an unreasonable partitioning. (In reply to William Brown from comment #16) > However, looking at the storage log only /boot, home_lv and swap_lv are > created. Is there an issue where anaconda can't kickstart with more than 2 > lvs defined? IMO this is not an unreasonable partitioning. There is nothing to suggest that this is related to your relatively simple ks.cfg. It did not get to the point of creating anything. It does find the old/preexisting home_lv and swap_lv and schedules them for removal. The reason you don't see any evidence of us creating your new layout that is because the installation process was interrupted, as reported here. Underlying cause is that subprocess.py is closing things it shouldn't be closing. *** This bug has been marked as a duplicate of bug 1103450 *** |