Bug 497374 - Traceback at beginning of EFI install
Traceback at beginning of EFI install
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-23 11:32 EDT by Will Woods
Modified: 2009-04-23 14:19 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-23 14:19:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached traceback automatically from anaconda. (62.63 KB, text/plain)
2009-04-23 11:32 EDT, Will Woods
no flags Details

  None (edit)
Description Will Woods 2009-04-23 11:32:47 EDT
The following was filed automatically by anaconda:
anaconda exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/iutil.py", line 106, in execWithRedirect
    except OSError, (errno, msg):
  File "/usr/lib/anaconda/storage/udev.py", line 169, in udev_trigger
    iutil.execWithRedirect("udevadm", argv, stderr="/dev/null", searchPath=1)
  File "/usr/lib/anaconda/storage/__init__.py", line 65, in storageInitialize
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
  File "/usr/lib/anaconda/gui.py", line 1330, in nextClicked
ValueError: need more than 0 values to unpack
Comment 1 Will Woods 2009-04-23 11:32:51 EDT
Created attachment 340958 [details]
Attached traceback automatically from anaconda.
Comment 2 Chris Lumens 2009-04-23 11:42:15 EDT
Can you reliably reproduce this?
Comment 3 Will Woods 2009-04-23 11:53:28 EDT
"need more than 0 values to unpack"? That's strange, isn't it? I'd assume it would be one value - the exception instance. But maybe my understanding of exception handling is incomplete.

Anyway, here's a suggested patch for execWithRedirect:

diff --git a/iutil.py b/iutil.py
index 0d7faed..7d354b7 100644
--- a/iutil.py
+++ b/iutil.py
@@ -103,8 +103,8 @@ def execWithRedirect(command, argv, stdin = None, stdout = None,
             if proc.returncode is not None:
                 ret = proc.returncode
-    except OSError, (errno, msg):
-        errstr = "Error running %s: %s" % (command, msg)
+    except OSError, e:
+        errstr = "Error running %s: %s" % (command, e.strerror)

Haven't tried to reproduce yet - restarting the install now.
Comment 4 Will Woods 2009-04-23 13:36:58 EDT
Hrm. Can't reproduce so far. Might be some kind of unreliable race with udevadm or something? Or maybe I just got a bad image? Who knows. I'll keep trying.
Comment 5 Chris Lumens 2009-04-23 14:19:07 EDT
Well, I've pushed your patch above for all places where we catch OSError.  I did the same thing in rhpl a little while back and haven't seen any new complaints.  Hopefully this will take care of it.

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