Bug 441336

Summary: Traceback from closing loop file descriptors (nfs install) SystemError: (22,'Invalid argument')
Product: [Fedora] Fedora Reporter: Jesse Keating <jkeating>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: dcantrell, franta, wwoods
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-05 13:51:00 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    
Description Flags
dump from anaconda none

Description Jesse Keating 2008-04-07 12:55:22 EDT
Right after partitions are made and formatted, anaconda tracebacks when trying
to close the file descriptors for loopback devices.  in isys.py:

try: _isys.locchangedfd(lop, targ)

It crashes when closing targ, which evaluates to '22'.

I can get this to happen every time I do nfs or nfsiso installs.  url (http)
installs don't seem to suffer this, haven't tried media installs yet.  This is
all booting from our new stage1/2 boot.iso.
Comment 1 Jeremy Katz 2008-04-07 23:33:48 EDT
Is this something new?  Also, can you get the complete traceback?
Comment 2 Jesse Keating 2008-04-07 23:54:03 EDT
Seems to be new yes.  I'll get the full logs tomorrow.  Got distracted with
other testing today :/
Comment 3 Jesse Keating 2008-04-08 15:10:05 EDT
And now I can't reproduce it at all.  Heisenbug.
Comment 4 Jesse Keating 2008-04-09 10:56:13 EDT
Hrm, this is back again, once I re-enabled the second disk of my system.
Comment 5 Jesse Keating 2008-04-09 10:56:53 EDT
Created attachment 301821 [details]
dump from anaconda
Comment 6 Chris Lumens 2008-04-17 05:09:44 EDT
*** Bug 441546 has been marked as a duplicate of this bug. ***
Comment 7 Jesse Keating 2008-04-17 10:00:17 EDT
Ok, now it no longer happens after the change to how we handle images in loader
for nfs.  Closing again.
Comment 8 Jesse Keating 2008-04-22 15:22:17 EDT
Crap.  It's back folks.  I can reliably reproduce when using NFS tree + boot.iso
booting.  Today's rawhide.  Requires that my second SATA disk is on and checked
as part of the installation.
Comment 9 Jesse Keating 2008-04-22 15:25:22 EDT
or now, it'll do it with just a single disk.
Comment 10 Jesse Keating 2008-04-22 15:51:48 EDT
I think I found the key.  When I use rawhide's boot.iso against a local compose
it fails.  Using my local compose's boot.iso against rawhide also fails.  Using
either directly with either will work.  Something is awry in the mismatched stage2.
Comment 11 Chris Lumens 2008-04-23 09:16:31 EDT
Die die die!
Comment 12 Will Woods 2008-05-02 15:48:54 EDT
Is there any reliable way to reproduce this, so we can test the fix? 
Comment 13 Jesse Keating 2008-05-03 19:41:51 EDT
The only way I could do it was to use a pungi created netinst.iso to do an nfs
install of rawhide.  Something in the mismatch would trigger the issue.
Comment 14 Jesse Keating 2008-05-05 13:51:00 EDT
confirmed fixed again.