Can yum resume??

[David]

On 10/23/2013 1:12 PM, Beartooth wrote:
> On Tue, 22 Oct 2013 15:51:52 -0400, David wrote: [....]
>> Excuse me. A question or two?
>> 
>> You messed up an upgrade over a week ago, maybe two(?), and you 
>> still have no solution.
> 
> Well, actually, since September 23. (My main question at that time 
> was whether the problem was in the hard- or software; and I don't 
> believe I've yet gotten a definite answer.)
> 
>> How would this time spend 'broken' compare with the time it would 
>> have taken to copy your important files, format the drive, and 
>> install the never release. Then put back your files and do the 
>> tweaks?
>> 
>> :-)
> 
> The immediate answer is that I concur with Joe Zeff and Javier
> Perez. I'm long retired (fifteen years next month), and little
> concerned with efficiency.
> 
> I don't know about you, but besides being an autodidact, I'm really 
> too old for this; I forget things, especially when backing up, even 
> if I'm not interrupted. Or worse, I give bad commands and get things 
> like a big file that includes a copy of itself, which includes (... ,
> etc., recursively, till the drive surrendered; that time I finally 
> did give up and install afresh.) When I last spent most of my time 
> learning things, the PC had not been invented.
> 
> The other approach would have taken more time, been more tedious as 
> well as more prone to error, and offered no chance to discover 
> something useful (nor to enjoy the intellectual company of the 
> better- instructed). Neither would it, afaik, have told me whether
> my hard- or software need healing.
> 
> For one thing, my trifocal fingers and arthritic eyeballs slow me
> way down. For another, my CLI-foo is minuscule -- I've probably
> studied too many languages (natural, not computer-) for too long, so
> that now those memory banks are overstuffed, whether or not the eyes
> and fingers function. (Anybody want a lecture on Old High German? 
> Minnesang? History of Balto-Fennic grammar?)
> 
> Also, the problem machine is my most expendable. If I succeed with 
> upgrading it (as I often do, believe it or not), then I can risk 
> tackling the next more important, and so up.
> 
> Having had occasional disasters with backing up, I seldom relinquish 
> an old machine, and keep several largely interchangeable, so that 
> when (not if) I bollix one so badly that I can't get it online, I'll 
> be able to keep up my normal activities while howling aside for 
> help.
> 
> What's more, with several machines I can do enough of the backing up 
> with a GUI instead of a CLI so that there's a much better chance
> I'll get it right. That bottom line in my .sig is what the late
> Goethe would have called "sehr ernste Scherze."
> 
> And I learn, slowly, but I do learn. I can often read a man page
> now, and even make a stab at which one to read.
> 
> Finally, I had a hunch that the downgrade would break again, but 
> respond to the completion command. Bad hunch :
> 
> [....] --> Processing Dependency: libcrypto.so.10(libcrypto.so.10) 
> for package: fetchmail-6.3.22-2.fc18.i686 --> Processing Dependency: 
> libcrypto.so.10(libcrypto.so.10) for package: 
> python-libs-2.7.3-13.fc18.i686 --> Processing Dependency: 
> libssl.so.10 for package: wget-1.14-5.fc18.i686 --> Processing 
> Dependency: libssl.so.10 for package: 1:qt-4.8.5-10.fc18.i686 --> 
> Processing Dependency: libssl.so.10 for package: 2:nmap- 
> ncat-6.40-1.fc18.i686 --> Processing Dependency: libssl.so.10 for 
> package: socat-1.7.2.2-1.fc18.i686 --> Processing Dependency: 
> libssl.so.10 for package: dillo-3.0.3-1.fc18.i686 --> Processing 
> Dependency: libssl.so.10 for package: stunnel-4.56-1.fc18.i686 Killed
> [root at T30 ~]# yum-complete-transaction BDB2053 Freeing read locks for
> locker 0x7c: 8855/3078112960 BDB2053 Freeing read locks for locker
> 0x7e: 8855/3078112960 BDB2053 Freeing read locks for locker 0x7f:
> 8855/3078112960 BDB2053 Freeing read locks for locker 0x80: 
> 8855/3078112960 Loaded plugins: langpacks, refresh-packagekit 
> rpmfusion-free- updates | 3.3 kB  00:00:00 rpmfusion-nonfree-
> updates | 3.3 kB 00:00:00 updates/19/i386/ metalink |  18 kB 00:00:00
> updates | 4.6 kB  00:00:00 updates/19/i386/ primary_db | 7.7 MB
> 00:00:03 (1/2): updates/19/i386/ pkgtags | 624 kB 00:00:01 (2/2):
> updates/19/i386/ updateinfo | 822 kB 00:00:01 No unfinished
> transactions left. [root at T30 ~]#
> 
> Hitting it with one more hammer also failed :
> 
> [root at T30 ~]# yum-complete-transaction --skip-broken Loaded plugins: 
> langpacks, refresh-packagekit No unfinished transactions left. 
> [root at T30 ~]#
> 
> At this point I began trying install disks. Oddly enough, the first 
> one enabled the brightness control; so meseems the hardware is not 
> broken yet. I'm in process of downloading a fresh DVD of CentOS 6.4; 
> this thread can be filed away. Having been through it, I plan to
> wait for F20 for my other machines, skipping F19 or perhaps running
> FedUp twice in short order ....


There is only one Linux distribution that I have ever had any real,
painless success upgrading from release, modified and used, to the next
release. And that is not Fedora. And no it is *not* Ubuntu.  :-)  The
only success *I* have had with a Fedora update was with a fresh install
of one release, run and updated, to a 'same-day' upgrade of the next
release. Nothing added or modified. Just the 'default' install.

I have however seen others that have talked about success but I have
never seen them mention any 'major changes'. I have seen what looks to
me like '3rd party stuff', you show rpmfusion, being a problem since
some 3rd party repos might not be enabled for the update.

I have never tried to downgrade a version but I have downgraded packages.

Fedora's rawhide, which updates daily, does actually update from version
to next version painlessly though. And contrary to popular belief is not
'always broken'.

I do not recall if you said that you and tried a Live-CD to test your
hardware against Fedora 19.

I feel your pain. But I think that you are trying to ride a sick, if not
dead, horse.  :-(
-- 

  David