Bug 441336 - Traceback from closing loop file descriptors (nfs install) SystemError: (22,'Invalid argument')
Summary: Traceback from closing loop file descriptors (nfs install) SystemError: (22,'...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 441546 (view as bug list)
Depends On:
Blocks: F9Blocker
TreeView+ depends on / blocked
 
Reported: 2008-04-07 16:55 UTC by Jesse Keating
Modified: 2013-01-10 03:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-05 17:51:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dump from anaconda (83.31 KB, text/plain)
2008-04-09 14:56 UTC, Jesse Keating
no flags Details

Description Jesse Keating 2008-04-07 16:55:22 UTC
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)
finally:
    os.close(loop)
    os.close(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-08 03:33:48 UTC
Is this something new?  Also, can you get the complete traceback?

Comment 2 Jesse Keating 2008-04-08 03:54:03 UTC
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 19:10:05 UTC
And now I can't reproduce it at all.  Heisenbug.

Comment 4 Jesse Keating 2008-04-09 14:56:13 UTC
Hrm, this is back again, once I re-enabled the second disk of my system.

Comment 5 Jesse Keating 2008-04-09 14:56:53 UTC
Created attachment 301821 [details]
dump from anaconda

Comment 6 Chris Lumens 2008-04-17 09:09:44 UTC
*** Bug 441546 has been marked as a duplicate of this bug. ***

Comment 7 Jesse Keating 2008-04-17 14:00:17 UTC
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 19:22:17 UTC
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 19:25:22 UTC
or now, it'll do it with just a single disk.

Comment 10 Jesse Keating 2008-04-22 19:51:48 UTC
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 13:16:31 UTC
Die die die!

Comment 12 Will Woods 2008-05-02 19:48:54 UTC
Is there any reliable way to reproduce this, so we can test the fix? 

Comment 13 Jesse Keating 2008-05-03 23:41:51 UTC
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 17:51:00 UTC
confirmed fixed again.


Note You need to log in before you can comment on or make changes to this bug.