WARNING:DO NOT UPGRADE TO CORE 4

[Matthew Saltzman]

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