On Thu, 14 Jul 2005, Gene Heskett wrote:
On Thursday 14 July 2005 08:20, Emmanuel Seyman wrote:
On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
Unfortunately, recovering from such kind of breakage is
non-trivial and often impossible ...
Is it? The repairdb page on rpm.org has always worked for me.
http://www.rpm.org/hintskinks/repairdb/
Emmanuel
I was going to follow these instructions, but there is no lib in
the /mnt/sysimage/var path. None, nada, zip. I left it with
memtest86 running, but I note something odd, I have a version 3.0 on
a floppy thats many moons old now, but the version on the rescue cd
says its 1.55. Why is a very valuable testing tool thats probably 6
or 7 years old being used today?
Umm, there are two packages called Memtest86. The one at
http://www.memtest86.com/ is at version 3.3. The one at
http://www.memtest.org/ (actaully called memtest86+) is currently at
version 1.60. The latter was forked from the former around version 3.0.
And, what happened to the boot option 'linux single' which used to
mount everything in r/w & drop you to a shell? That did a normal
boot up to the point where it should have started X, but x is now
fubar & gets into a loop of a blue screen with an X, then going
black, then repeat, each time doing it more slowly until the blue
screen becomes contaminated with stray data. At that point I 3
fingered it.
Works for me if I add 'single' to the kernel line in Grub. Single-user
mode should *not* attempt to start X.
If you are trying to boot in rescue mode from the rescue CD, type "linux
rescue", not "linux single". The rescue CD won't try to start X either.
FC4 looked pretty good, till I turned yum loose to update it, useing
only the contents of /etc/yum.repo.d as just installed. And yum
proved once more that it exists only to commit hari-kari. Only this
time it took the whole, freshly installed & apparently 100% working,
system down with it.
After memtest runs a couple of loops, I'm going to do a clean install
one more time. But as a test, I'm going to reenable the main repo
addresses in those files, screw the mirrors. Before I do a yum
update again.
Seriously folks, stuff like this should never be allowed out the door,
and we need an FC4-1 release that fixes whatever the hell is screwing
this up.
Look, lots of folks have installed FC4 and are regularly and successfully
performing updates. I'm not saying there are no problems. I'm not saying
that whatever unusual property of your system or unusual action that
you've performed didn't uncover a bug (perhaps even a serious one). But
you have to realize that it is impossible for the developers and beta
testers to test with every hardware combination or to anticipate every
crackpot sequence of actions that a user might take. When bugs are found,
the bug finder and the developers need to work together to recreate and
diagnose the problem. Then the developers need to fix it.
I haven't been following this thread very intently, but from skimming some
of your earlier messages, it appears that you have some unusual
configuration on the problem machine, with a couple of disks and a couple
of versions of FC.
Maybe it would help to slow the process down and do some
reasonableness and consistency checks after the install and before the
updates. Then do the updates in chunks and see if you can narrow down
where the failure occurs.
But you have to understand that by now, there is no way in hell I'd
touch this working FC2 system with an FC4 install. This one may not
have a working yum, and has enough tarballs installed, largely
because of FC2's long standing bugs re cups vs kde, that apt-get
wants to remove about 90 packages from the heart of the system just
to "clean it up".
yum seems intent on destroying yum, at least on this FC2 system.
It never heard of the hypocratic oath, first, do no harm.
It was yum that destroyed yum here, by installing an incompatible
libxml2.so that no one can tell me how to fix, other than going back
to the original cd's and forceably reinstalling that yum and all the
xml & python related stuff. I've done that three times now, but will
have to burn another set of FC2 cd's before I can do that again. I
ditched mine when FC4 final came out. Silly boy...
If and when I ever get an FC4 install working again, is there a
sequence I should be using so that things get updated in the right
order next time? Like resetting /etc/inittab to 3, so x isn't
running when yum tries to update it, and other things like that need
to be known?
?????
You should be able to update a running X and then restart it. I've done
it lots of times.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
