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.
