Installing livecd from USB stick - Bug #502771 - Investigation and patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.  - Not
subscribed please CC.

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

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux