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@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@T30 ~]#
Hitting it with one more hammer also failed :
[root@T30 ~]# yum-complete-transaction --skip-broken Loaded plugins:
langpacks, refresh-packagekit No unfinished transactions left.
[root@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