Re: WARNING:DO NOT UPGRADE TO CORE 4
From: Gene Heskett (gene.heskett_at_verizon.net)
Date: Thu, 14 Jul 2005 14:32:13 -0400 To: For users of Fedora Core releases <firstname.lastname@example.org>
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.
>> 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
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
-- 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. -- fedora-list mailing list email@example.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list