I think the approval queue ate my first email, let's try this again... ---------- Forwarded message ---------- From: Eric Kerin <eric_kerin@xxxxxxxxxxxx> Date: Thu, Jul 9, 2009 at 4:18 PM Subject: Installing livecd from USB stick - Bug #502771 - Investigation and patch To: anaconda-devel-list@xxxxxxxxxx Cc: clumens@xxxxxxxxxx I put this in bugzilla in the closed bug - it was marked as a duplicate of another, it was suggested that I post it here. Quick summary - mke2fs will finish it's work quickly, and anaconda will spend quite sometime reading in the output, and updating the progress dialog in certain cases - the attached patch adds a check to the read/progress loop to check to see if the process has finished, and jumps out early if that's the case. Long story - I'm working on a netbook livecd install for Fedora. With the screen size of the machine I have to test on, anaconda goes into full-screen mode, the progress dialog goes full-screen as well (and remains hidden too, have not checked into this yet), it looks like because of this, it takes a long time for the progress pulses to return. (FYI - my machine also happens to be running maximus, but anaconda is excluded from it's maximizing effects) I ran into the same problem as others have, where you can hit next early, and applied the patch to make the progress dialog modal, but still ran into long periods of time where it was "formatting" with no disk IO. A quick check, and mke2fs was defunct, and anaconda was using up CPU nicely. I did some digging, and found that it was still reading the stdout data from mke2fs (it was printed very slowly, one character at a time to /dev/tty5) What I found, was that since iutil.py's execWithPulseProgress method reads one character at a time, in cases where the progress.pulse() method takes a long time to return, it slows up the reading of data, and the eventual reaping of the process. Which manifests as a defunct mke2fs process. If you give it long enough, it will continue the install. Long enough being 10 minutes or so, depending on your system. There's a loop in gui.py that smooths the pulses if it took a long time between calls, that's where a lot of the delay is spent, doing processEvents(), and because of the loop and smoothing it can start to take even longer - the first call to pulse that waits is is for <1s, next one smoothing a delta of 5 seconds, the next call is for 20 s delta, then 80 s delta...Eventually, it reads every character, after this exponentially increasing wait state. The attached patch does two things, only the change to iutil.py is really necessary - it just checks to see if the child process has exited already, and breaks if it is, since we don't need the output of the child process anyway. The patch for gui.py just keeps the delay from getting exponentially longer. Thanks, Eric Kerin
Attachment:
anaconda-11.5.0.59-fix-defunct-mkfs.patch
Description: Binary data
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
