On Fri, Aug 24, 2018 at 2:13 AM Yasha Karant <[log in to unmask]> wrote:
>
> The pre SL 7.5 machine for which yum crashed during an upgrade does
> boot.  I ran parted as root on the hard drive with the following output:
>

[ RAID information snipped ]

"RAID" can means a lot of different settings, most of which are not
evident from the data you published. You've sometimes tried to
outsmart standard settings, so it's not clear if the XFS partitions
are elements in a RAID array, or have been gathered into LVM groups,
or what.

> would not image the mirrored "RAID" drives from one of the mirror set?

In theory, mirroring a drive by replicating to a another drive or a
disk image should copy all the content. But it can also confuse the
system, because it copies the uuid's of the partitions to the new disk
or disk image. Chaos can ensue. Having both drives attached at the
same time, in that setup, can be..... well, it could trigger
adventures. That kind of thing is partly why I recommended using a
live CD or DVD image, even if it's on a USB drive.

> By this means, all of /home , /opt  and the like should be recoverable?
> There may be minor discrepancies but as the system was not being used
> other than for root to run yum, the image should have all vital
> configuration files as
> well as all end-user home directories.
>
> Also, as the system does boot, is there anyway to start yum "fresh" and
> force an upgrade at this point?  Only the Xwindows system fails under

It would help your models if you looked, not at "yum", but at the
underlying "rpm" tool that yum actually uses. yum is a wrapper for
RPM, organizing *what* packages to manipulate with RPM underlying RPM
commands like "instlal", "update", or "delete". It's why I suggest
reinstalling all the packages with "rpm -U --replacepkgs", from a list
of installed packages. Since you have a 2 TB drive lying around, you
can even pre-mirror the current yum repositories to directories there
and work from local copies. There are scripts for just that sort of
mirroring at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_nkadel-2Drsync-2Dscripts&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=hjaUISXTxcYgW6W-uGgZnd2OCi2FD6KjF41CYpZbHEA&s=UhoMe2yWOrvF-XYZQqLGOG62ksAu5fjKA00OMrO4qaQ&e=. They're a
bit out of date, but there is one there specifically for Scientific
Linux.

> the old system.  During the boot sequence, one can choose the SL7.5
> image, but this one fails with a panic due to the yum upgrade failure.

See what I've been saying about "re-installing all your RPM's, with
the 'rpm -U --replacepkgs'" options.

> However, the older system image does boot as the above output serves t
> verify.  My guess is there are one or more yum bookkeeping files that
> need modification for a "fresh" yum update to be enabled.
>
> Any further assistance would be appreciated.
>
> Yasha Karant

Maybe a "grubby" misconfiguration when the kernel was being installed?
Like I keep saying, "re-install the RPMs". I suspect that will address
your issues. And, if I may say from personally recovering critical
systems from failed upgrades, including incompatible kernels? Been
there, done that. The re-install can be done from a live DVD or USB
drive, and it's pretty effective. Slow, but effective.