Piruit (Add/Remove Software) crashes several times - solution!
Dan Thurman
dant at cdkkt.com
Wed Mar 29 17:02:55 UTC 2006
On Wed, 2006-03-29 at 19:53 +1100, David Timms wrote:
> Dan Thurman wrote:
> > Folks,
> >
> > Just be aware that your mileage may vary but Pirut
> > (Add/Remove Software) isn't very reliable and expect
> > it to crash on you. I have used this program several
> > times and several times it has crashed and wiped out
> > hours of downloads in an instant. Yes, ALL of the
> > cache downloaded RPM files are gone in an instant!
> >
> > My last download was 4 hours and it all but went down
> > the tubes and all for natch.
> The defaults for caching the downloaded headers and packages has changed
> from leaving on your disk to erasing them.
>
> For other reasons (multiple FC5 machines to update), I definitely do not
> want yum to be erasing packages as it finishes with them.
>
> In /etc/yum.conf: change
> keepcache=1
> Then if something did go amiss you would *not* have to re-download all
> the files :-)
>
> I have definitely tried lots of different things: uninstalls, add
> packages from extras/core/freshrpms, and removes as well, no problems so
> far.
>
> But a bugzilla would be good, and I'd be happy to file it on your behalf
> but I'd really need your memory of what steps where made in the lead up
> to the explosion; with out this info, it is unlikely to be repeatable
> and hence get fixed (therefore we effectively are collectively shooting
> our selves in the feet).
>
> On a side note: is there plenty of space on the /var partition (eg. df)?
>
> DaveT.
>
I have completed all of my installations for FC5 and in retrospect
it would have been better for me to have had a root canal operation
at my dentist's office with a spit-bowl for blood and bits of foreign
junk that occasionally crops up. :-p
I have experimented around and did a combination of things with piruit
and I will try to summarize my findings as best as can and as best as
I can understand the symptoms...
1) Your mileage my vary but for me, it happens 100% of the time:
a) Open piruit and by default, you should have groups listed
and it shows starting with "Desktop Environments" to the
left and "Gnome Desktop Environments" to the right panel.
b) For each group on the left and right, choose the 'Optional
packages' button and when it appears, check off ALL of the
items listed. When you have completed this long ordeal,
click the 'Apply' button. Go on a break and depending on
your connection speed, this is gonna take some time!
Note: Due to package conflicts do not choose proftpd if
you choose "All" items because you will NOT be able
to go back and unselect this item. Piruit is a ONE
TIME SELECTION process - it is not designed to allow
you to make corrections after you hit the 'Apply'
button. Piruit as it is, is a KISS and an extremely
simplistic (but broken) design IMHO.
It is here where I got a crash-dump. When I complied with a
dialog message asking for the filename of the crash dump and
clicked "OK", I believe it may be after this point that piruit
destroyed all of the RPMs but I cannot be sure. It is possible
that if you do not complete the crash-dump process w/o first
checking the cache, you might be able to recover the download
time and run rpm -Uvh *.rpm and remove it BEFORE attempting to
save the crash-dump dialog box. Of course, it is not complete
because it crashed before it got all of the RPMs selected.
2) Repeat (1a) but instead of choosing all the items, choose a smaller
group of items and babysit the process. This is a LONG and TIME
CONSUMING process. No fun.
a) Sometimes you might see an occasional "hang", so instead of
of waiting and waiting and waiting, I have gone into:
/var/cache/yum/{core,extras,updates}/packages and directly
ran: rpm -Uvh *.rpm, and specifically deleted or off-moved
the RPMs into a sub-directory. This is guaranteed to work
but this step was something I did when I was tired of losing
RPMs or did not want to take the chance that piriut would remove
it. For testing, just go through it until there is a problem
if you want to find out what the cause of the problems are.
NOTE: If you watch your LAN-switch with lights (I have an
expensive one) you might get to notice that there are times
that the specific items being requested for downloads are
"hung". It almost seems that internally to piruit, it
keeps on trying, perhaps even cycling through the mirrors
trying to get a mirror to serve a request but is unable
to. I am guessing that memory is getting eaten up while
all of this is going on behind the scene but I cannot be
sure of that. All of this is purely SUBJECTIVE since all
the details of what is really going on in piruit is not shown.
Yumex shows exactly what is being logged so that faults can
be pinpointed but piruit hides everything so piruit should
allow detailed logs to exist somewhere for diagnostics.
Ok, here you go! Thanks for handling this on my behalf!
Dan
More information about the fedora-list
mailing list