Re: WARNING:DO NOT UPGRADE TO CORE 4

From: Gene Heskett (gene.heskett_at_verizon.net)
Date: 07/14/05

  • Next message: Gene Heskett: "Re: gnome terminal history [was Re: WARNING:DO NOT UPGRADE TO CORE 4]"
    Date: Thu, 14 Jul 2005 14:32:13 -0400
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    

    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.
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Gene Heskett: "Re: gnome terminal history [was Re: WARNING:DO NOT UPGRADE TO CORE 4]"

    Relevant Pages

    • Re: Fedora home server using core 9
      ... See SL.documentation for Upstream vendor release notes. ... also install java-1.5.0-sun-compat ... These are dependencies of the above rpms. ... Yumex is a graphical user interface for yum. ...
      (Fedora)
    • Re: Cant find existing Fedora on FC3>FC4 upgrade
      ... filing a bug report against anaconda. ... >condition or whenever yum went down due to sql-lile or something. ... This will install the repos and other information ... only a few packages were needed after trying the ...
      (Fedora)
    • Re: F7 looking [not so] good here.
      ... yum and not file different ones against individual graphical front end's. ... so that's what I report the bug on. ... livna-release-7.rpm to get livna repos added to yum, ... To get my additional packages, I just searched for stuff to install, ...
      (Fedora)
    • Re: Problems Finding In Yum Install!!!
      ... 1.For the command:- yum -y update ... -d debugging output level ... yum install openldap openldap-devel nss_ldap openldap-clients ...
      (Fedora)
    • Re: WARNING:DO NOT UPGRADE TO CORE 4
      ... If you are trying to boot in rescue mode from the rescue CD, ... > After memtest runs a couple of loops, I'm going to do a clean install ... Before I do a yum ... you've performed didn't uncover a bug. ...
      (Fedora)