WARNING:DO NOT UPGRADE TO CORE 4

[Gene Heskett]

On Thursday 14 July 2005 12:36, Matthew Saltzman wrote:
>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.
>
Any special reason for the fork?  This one does seem faster, like some 
of the more time consuming bit twiddling tests are left out.

>> 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.

2 disks yes, but the other install, on the second disk (or it was 
anyway) was a debian based install of emc via the brain dead 
installer, version 4.08.  It uses adeos to run machinery in realtime.

>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.

This ones always had problems doing any of that while x is running.  
But now yum has installed a new kernel, and it won't boot at all.

>--
>   Matthew Saltzman
>
>Clemson University Math Sciences
>mjs AT clemson DOT edu
>http://www.math.clemson.edu/~mjs

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.