CentOS - Jan 2011 - how to move forward/undo/revert/fix re: a failed CentOS 5.5 to SL 5.5 migration ... [SOLVED?]

On Wed, Jan 26, 2011 at 11:25 AM, Larry Vaden <vaden at texoma.net>
wrote:
> For various reasons which seemingly fail the necessary/sufficient
> tests with the benefit of hindsight, I attempted to migrate a shell
> machine which is the beach front from which I work (not a production
> server) from CentOS 5.5 to Scientific Linux 5.5 yesterday.
>
> Karanbir is quoted on this list as having said something like:
>
> "All that you should need to do is install centos-release, remove
> redhat-release rpms and just yum update the machine, which should
> bring in all packages changed by CentOS ( since they will have a
> slightly higher E-V-R )."
>
> In other words, is there a get out of jail card based on Karanbir's
> stanza which will return the machine to a consistent state without a
> fresh install?
With apologies for replying to my own post, the final solution
(possibly regarded as draconian and puerile by others) which seemed to
work to return to a consistent state was to download Oracle R5U6 and
invoke 'rpm -ivh' following some rpm which must be set aside in order
to avoid "can not coexist." (e.g., bind vs. bind97 et al).

My thoughts are that it would work as well once CentOS and Scientific
Linux R5U6 are released.

It was necessary to pay special attention to the output of

updatedb; locate .rpm | egrep ".rpmnew$|.rpmorig$|.rpmsave$"

No data was lost, but I watch some Dennis Miller, and like him at the
end of a rant, "I could be wrong about that" :)

kind regards/ldv

Larry Vaden wrote on 01/30/2011 08:41 PM:
...
> With apologies for replying to my own post, the final solution
> (possibly regarded as draconian and puerile by others) which seemed to
> work to return to a consistent state was to download Oracle R5U6 and
> invoke 'rpm -ivh' following some rpm which must be set aside in
order
> to avoid "can not coexist." (e.g., bind vs. bind97 et al).
So, out of morbid curiosity, and because it seems to have been my post 
on the SL list you quoted that helped get you into this state, was 
anything other than the replacement process actually broken?

It is completely unsurprising that the kernel RPMS failed to install 
over the like versions, but I would have expected things to work with 
the CentOS kernels on the SL/CentOS mixed system.  The replacement 
process was only suggested as something for those really paranoid about 
not having all the packages from the same distro to try, and I certainly 
would not have endorsed throwing Oracle into the mix.  For the record, 
if I really wanted to replace the kernels, my process would have been 
something like:

1. Boot from an older <OldOS> kernel.
2. Remove the newer <OldOS> kernel[s].
3. Install the latest <NewOS> kernel with yum.
4. Reboot to the <NewOS> kernel.
5. Remove the remaining <OldOS> kernel, or perhaps better leave for a 
fallback.

By the way, my initial post in the SL thread started: "The procedure 
(untested by me) should be similar to the procedure on the
CentOS Wiki for migration from RHEL to CentOS...".

Caveat Emptor! :-)

Will be interesting to see how you fare with your three-way hybrid when 
CentOS 5.6 hits the mirrors.

Good luck,
Phil

On Wednesday, February 02, 2011 09:31:43 am Larry Vaden
wrote:
> "* The host/dig/nslookup utilities queried only servers from
> resolv.conf. With this update, the utilities query the servers
> specified on command line instead of in resolv.conf and the issue is
> resolved. ( BZ#561299)"
> 
> The official release notes imply that the argument on the command line
> was ignored and the contents of /etc/resolv.conf were used instead
> which should lead to consistent results between the two invocations.
I think the release notes do not reflect the actual bug, in this case.  The bug
text is:

"I have noticed that release 5.4 (Final) appears to ignore the server
option
when using host or nslookup if the host in question is not available.

The commands should return no server available as they have in the past
but instead decide to query the servers specified in resolv.conf and return
results from that."

As both of the servers you gave in the message provided results, the queries
given do not trigger the actual bug; that is, if the server referenced is not
available or does not return a result, *then* it went to the servers in
resolv.conf rather than the previous behavior.

Fault lies in the writer of the release note bullet point, which does not
accurately describe the bug actually fixed.

And that explains why  'host www.yahoo.com 208.67.220.220' and 'host
www.yahoo.com 8.8.8.8' got completely different answers, as I know OpenDNS
does fairly aggressive caching that semi-ignores $TTL, and google (8.8.8.8 is a
google DNS server) probably does too.